08 - Tabs and audience targeting

Info: This article is work in progress and subject to change.

A single Workflow Assistant panel can serve more than one audience. Editors, reviewers, production staff, and managers often need different views of the same asset — different fields, different actions, different decisions. The Configurator handles this with tab-level audience targeting: each tab can be shown to one or more Assets user groups, and users only see the tabs their groups grant them.

This article covers how audience targeting works, how to configure it, and the patterns and pitfalls of a multi-audience panel.

For the conceptual material on tabs as a structural element, see 02a — Panel anatomy.

How audience targeting works

Each tab has an audience (access permissions) setting — a list of Assets user groups that should see the tab. The Workflow Assistant compares this list to the groups the signed-in user belongs to:

• If the user belongs to at least one of the listed groups, the tab is visible to them
• If the user belongs to none of the listed groups, the tab is hidden — completely. There is no “you don’t have access” message; the tab is rendered as if it did not exist
• If the audience is set to All, every user with the Required role sees the tab

Audience targeting is independent of the asset-kind visibility checklist on individual components. A user might be allowed to see a tab but find that everything in it is hidden by per-component visibility — which is a different problem with a different fix.

Note: Tabs hidden by audience targeting are silent — no error, no warning, no empty state. This makes the feature safe (a user cannot accidentally reach a tab they shouldn’t see) but also makes a misconfigured group mapping invisible. Always verify multi-audience panels by signing in as a test user in each group.

Configuring a tab’s audience

Step 1. In the Configurator, select the tab you want to target.

Step 2. In the options panel on the right, find the Access permission  icon.

Step 3. Pick from:

• All — every user with the Workflow Assistant Required role sees this tab
• One or more named groups — only users in at least one of the listed groups see this tab

Step 4. Save changes.

The list of available groups comes from your Assets installation. If a group you expect is missing, the group does not exist in Assets — work with your Assets administrator to create it.

Tip: Test users sometimes mismatch what you expect. After configuring a tab’s audience, sign in as a real test user from each group and verify each one sees what you intend. The two-window verify habit is the same one used in the Quick Start tutorial.

Patterns

One audience, one tab

The simplest case. Use a separate tab per audience, with the audience setting on each tab restricting it to the right group.

Users in Editors see only the Editor tab. Users in Reviewers see only the Reviewer tab. A user who is both an editor and a reviewer (a senior who covers both roles) sees both tabs.

A shared first tab plus role-specific tabs

Sometimes every audience needs a quick-orientation tab. Add a shared tab targeted to All, then role-specific tabs:

The Overview tab carries the Notification, the asset facts, and any always-on context. The role-specific tabs carry the actions each role takes.

Admin tab visible only to admins

A tab that exposes deeper controls for power users — bulk operations, advanced metadata stamps, debugging actions:

Only members of the named group see this tab. The rest of the audience is unaware it exists.

Anti-patterns

Mixing audience-specific fields in a single tab

The wrong way to support multiple audiences:

• One Editor / Reviewer tab with every editor field and every reviewer field
• Field-level visibility tries to compensate by checking against metadata fields (“show this field if the user’s group is X”)

This produces a busy tab with components flickering in and out and confuses users. Always split audiences into separate tabs, not separate components within a tab.

Identical tabs with tiny differences

If you find yourself building two tabs that are 95% the same but with one or two different actions, simplify: keep one tab targeted to All and use Disable conditions on the audience-specific actions instead.

This is the rare case where merging is right; in general, split. Use the rule of thumb: if more than three components differ between two tabs, they should be separate tabs.

Forgetting the All-targeted onboarding tab

If your panel has only audience-targeted tabs, a new user with the Required role but no group membership sees an empty panel. Always include either an All-targeted tab or a Notification (with No asset ticked and an All tab) that tells unrecognised users where to go.

Diagnostic: why is the user not seeing the tab I configured for them?

Most invisible-tab questions are resolved by question 2 (the user is not in the group) or question 3 (the audience setting on the tab does not list the user’s group).

Cross-references

• 02a — Panel anatomy — tabs in the four-level structure
• 04a — A design methodology — when to split audiences into separate tabs
• 04b — Patterns and anti-patterns — the “mixing audience groups” anti-pattern
• 06a — Showing components for the right asset kinds — for visibility within a tab once audience is right
• 09 — Testing, and saving — for the publish step that brings audience changes live

Revisions

• 7 May 2026: First publication of the manual