Demoing Role-Based Permissions Without Losing the Buyer Story

A permissions demo should show who can see and do a specific task, not display a large settings page and hope the buyer infers the effect. Use test accounts for each role and a shared fictional record.

Define the permission question

Write one question before building: “Can a reviewer approve a request from another department?” Identify the roles, object, action, and policy that determine the answer. If plan or configuration affects access, include that context.

Show the default state, the administrative change, and the resulting views. The same record should remain recognizable when the presenter switches accounts.

Demonstrate both allowed and blocked actions

The buyer should see the control available to the authorized user and absent or disabled for the other role. Explain the reason in plain language. Avoid using a hidden UI element as the only evidence of enforcement; a technical buyer may need a separate authorization test.

For example, after granting a manager review rights, the manager can approve request #104 while the requester can only read its status. The live path establishes what happened in that configured environment. It does not prove every policy combination.

Prepare the technical follow-up

Record the environment, role definitions, policy settings, and any inherited permissions. Ask the buyer which roles they need to map. If their identity provider or custom policy matters, schedule a focused test rather than promising equivalence from a generic demo.

The interactive admin-permissions guide shows how to tell this story in a self-guided format; a live demo can go deeper into configuration and questions.

Follow one record across roles

A fictional requester creates an item and sees its own status. A manager opens the same item, chooses approve or send back, and the requester then sees the result. Use role labels on screen at every transition and show the boundary: the requester cannot open the manager decision controls.

Test with separate accounts or a verified role switch, not an admin account that can see everything. Record the exact action available to each role, the plan or configuration required, and any restricted data. If the product uses a different permission model, adapt the scenario to actual behavior.

A buyer should be able to answer three questions afterward: who initiates the task, who decides, and who can view the outcome. If they cannot, shorten the story or add a clear handoff frame. The multi-role interactive demo applies the same boundary to a self-guided format.