Issues

What degraded during assembly, and where. Under Observe → Issues.

How it works

A payload rarely fails outright. It degrades: an enrichment throws, field-level security strips a field, a formula can’t evaluate, and the agent still gets an answer with less in it.

The page covers the last 14 days. Each row is one day of one problem: the entity, a category, the item that failed, how many times it happened, a sample message, and when it was last seen.

Rows split by domain too, so the same problem through two domains lands on two rows. Only Trends names the domain: its Recent Issues list carries a domain column, and its table counts issues per domain, week over week.

CategoryWhat happenedUsually means
fls_stripA curated field was stripped by field-level securityFix the permission set, or drop the field
element_failureA metric, formula, or enrichment threwA broken expression, a provider bug, or a source that no longer exists
config_invalidA definition couldn’t be resolvedA renamed field or relationship, or an element used where it doesn’t apply
hard_errorAssembly itself failedRare — the sample message names the cause

The first three categories are entity degradation: a payload that arrived with less in it. A catalog read has no partial state — it serves whole or fails. A catalog failure files here as a hard_error row named (catalog).

Best practices

  • Check Issues after every change. A failing formula or enrichment is silent to the agent — make this the last step of any edit.
  • An empty page is the goal. Every row is something to fix or deliberately accept.
  • fls_strip is common and often correct — the real question is whether the entity should still carry a field its audience can’t see. If not, remove it and reclaim the tokens.
  • element_failure deserves immediate attention. A section is missing from every payload, and the agent’s answers still look complete.

What’s next