Content Approval Workflows

A content approval workflow is a defined sequence that content must pass through before it reaches a screen, answering four questions: who creates, who reviews, who approves, and who publishes. The standard shape is create → submit → review (with a revise loop) → approve → schedule → publish → monitor. It exists because a screen is a broadcast: an incorrect price on a menu board, an outdated promotion, or an off-brand graphic is visible to every customer in the venue until somebody notices, and 'somebody notices' is not a control.

It depends on who owns what, and the cleanest split in practice is: brand owns the templates, local teams own the messages inside them, IT owns the devices, and compliance owns the exceptions. That way a branch manager changing a local offer does not need brand approval — the template already enforces the brand — while a new campaign or a regulated message does. If you cannot name the single person accountable for what is on a given screen right now, you do not have a workflow, you have a group of people with logins.

No — Elementi does not enforce approval itself, and this is worth knowing before you design around it. The workflow is implemented externally: the designer creates content in Elementi, shares the project file or a preview for review, the reviewer approves via email or a task-management tool, and an authorized person publishes the approved content. For teams that want the gate enforced by the platform rather than by process, Arya's role-based permissions are the mechanism — see the next question.

Split creation from publishing at the permission level rather than by asking people to be careful. Arya supports role-based access in which some users can create content but only specific users hold publish permissions, which creates a natural approval gate: creators design, publishers review and deploy. This two-role model — create → approve/publish — is the minimum viable workflow, and even on its own it catches most quality issues. The failure mode it prevents is the common one: every employee holding publish access to all screens, which produces inconsistencies, errors, and brand damage without anyone doing anything wrong on purpose.

Match approval depth to content risk, not to org chart politics. Low-risk content — data-driven widgets, templated updates, a weather panel — needs minimal or no approval, because the template already constrains the output. High-risk content — new campaigns, pricing, regulated disclosures, anything on a screen with legal, financial, or reputational exposure — earns a thorough review. Five approvers for a weather widget update is not caution, it is a bottleneck, and bottlenecks are how teams end up bypassing the workflow entirely.

A 4–24 hour approval SLA is the standard working range for non-urgent content: fast enough that people do not route around the process, slow enough to allow a real review. Add auto-escalation if an approver does not respond within the SLA window, otherwise a single person on holiday silently becomes an outage for the whole content pipeline. The SLA is the part of the workflow most often left undefined and most often responsible for its abandonment.

Yes — require a visual preview for every approval, with no exceptions. Approving from a description or a filename misses exactly the class of problem that approval exists to catch: layout breakage, font rendering and ligature failures, colour accuracy, text overflow, and right-to-left issues in bilingual layouts. Use the Elementi preview or a staging player so the approver sees what the screen will actually render, not what the source file implies.

No — emergency content must bypass approval entirely. If the building is evacuating and the alert needs three sign-offs, the workflow has become a life-safety hazard. The correct design is to pre-approve the emergency templates in advance and designate emergency publishers who can deploy them immediately: the approval happened once, at design time, so it does not have to happen during the incident. Regular content follows the standard flow; emergency content goes live instantly.

With tiered approval that follows content ownership: local teams approve regional content, corporate marketing approves brand-level content, and the two do not queue behind each other. Arya's group permissions support this directly — regional managers control their own locations while HQ controls global content. Keep an audit trail of who approved what and when: on a multi-region network it is the only way to answer the question that always eventually gets asked, which is how a given item reached a given screen.