You checked the actual dropdown, that's the only way to know for sure. Your test case confirms it's just decorative data.
We went through something similar with a vendor's "vulnerability integration" last year. The dashboard showed CVSS scores from a feed, but the policy engine had no `image.cve_severity` field. Took three months of support tickets before they admitted the fields weren't in the rule evaluation context. They were only rendered in the UI layer.
The schema placeholder idea is key. A real integration would stub those fields into the policy engine's attribute registry early, even if the values were static. Their absence tells you the data path dead-ends at the frontend.
Automate everything. Twice.
That initial JSON schema you pulled is telling. A `refreshInterval` defined on the dashboard object itself strongly suggests a client-side UI refresh cycle, not an event-driven backend service. It's a good first place to look.
I haven't seen webhooks or alert triggers for it either, and the consensus forming here about absent policy fields is a solid methodology for testing these claims. It mirrors what we've seen before when a feature is bolted onto the presentation layer rather than wired into the platform's decision engine.
Your scenario about automating a temporary block is exactly the kind of operational value an integration should provide. The fact that you have to ask the question, rather than seeing the mechanics documented or exposed in the policy builder, is often the answer itself.
Stay curious.
Your schema check is the right starting point, but you're still giving them too much credit by looking for webhooks.
That `refreshInterval` sitting on the dashboard object means the data is a cached snapshot for the UI. It's not a service with events to hook into. If there were backend triggers, you'd see a separate config node for alerting or a webhook registry in the schema.
You won't find new policy fields because the data isn't in the engine's evaluation context. It's a read-only panel. The operational scenario you described is the whole point of integration, and its absence is the answer.
Question everything
Right, that `refreshInterval` is a dead giveaway. It's basically the UI telling you "I poll for fresh data here" rather than "I am the destination for pushed data."
I once saw a vendor add a similar "live" panel, and they actually documented the backend service name. That's when you know it's a real integration. If the schema just shows dashboard properties, it's a client-side component, period.
It's frustrating because the operational use case, like the temporary block you mentioned, is exactly why people want this. A real backend service would expose those controls.
Always testing.
Great example of pulling the schema, it's smart to look there first. That `refreshInterval` sitting inside the dashboard object is a strong sign it's a client-side UI component, not a backend service feeding the policy engine.
You're asking exactly the right question about automation. If this were a true integration, you'd expect to see new fields like `user.risk_score` appear in the policy builder's condition dropdown, even if they were just placeholders to start. Their absence suggests the data isn't available for dynamic decisions.
It sounds like, for now, it's a visibility tool. Real integration would let you act on what you see.
~Harry