Demonstrate Two User Roles Without Giving One Account Every Power
Demonstrate Two User Roles Without Giving One Account Every Power
Most role demonstrations aren't dishonest. They're convenient. The person showing the product is signed in as an administrator, because that account was the one that could load the fixture data, and signing out and back in costs two minutes. So one identity creates the request, submits it, approves it, edits the record and opens the report, while narration covers the joints: "your requester submits this, then your manager approves it here."
The buyer can't tell which parts of that sentence are permissions and which are captions. That's the cost. A role-based demonstration should show what each person can do, what each person can see, and what each person has to wait for — and the waiting is where a buyer's own users will spend most of their week.
The alternative isn't a bigger script. It's a smaller claim, made carefully: two authorized accounts, one shared object, and an honest record of who was allowed to move it.
Who acts, on what, inside which scope
Start from the product owner's permission description, not from the role's name. In many systems, access is decided by three separate things acting together: the identity doing the action, the set of actions that identity is permitted, and the resources the permission covers. Microsoft's overview of Azure role-based access control describes exactly that combination — a security principal, a role definition, and a scope — and it's a useful way to organize your questions even if the product you're demonstrating has nothing to do with Azure.
Those three questions sound like this in practice:
- Who is acting? Which account or identity, specifically. Not "the requester" as a category, but the account you will sign in with.
- What may that identity do? Create, view, edit, submit, approve, receive a notification. Ask which of these are permitted and which are not.
- Over which resources? Every request in the system, only their own, only requests in their department, only requests assigned to them.
Ask the owner for the answers in writing, as a permission matrix you can check later against what you saw. A job title is not a permission. Neither is the name of a role in a dropdown. "Approver" might be a job title in the buyer's org chart, a role in this product, a group in the identity provider, or all three with different meanings. Only the owner's description of the configured permission tells you what the demonstration is actually showing.
One more question worth asking before you build anything: does the account you plan to use as the "ordinary user" hold more than one role assignment? The Azure page covers effective access when more than one assignment applies, and the reason to care is simple. An account can look narrow on screen — a small menu, a short list — while still holding permissions from a second assignment or a group membership that nobody mentioned. If your requester account quietly carries approver permissions, your demonstration will run beautifully and prove nothing.
Two accounts, one object, and an administrator kept off stage
Demonstration identities should hold only the access the role is supposed to have, and the fixture data should be dull: invented names, invented amounts, nothing that belongs to a real customer or a real employee.
Do the setup separately. If an administrator has to create the accounts, assign the roles, or seed the records, do that before the demonstration starts and say so out loud. "This was set up in advance by an administrator; the rest of this runs in the two accounts you'd give your own staff." One sentence, and the buyer now knows which parts of what they're watching are ordinary use.
What you're avoiding is subtler than cheating. It's the moment where the administrator account stays signed in through the whole story and the narrator says "your requester can do this" while an account that can do everything performs it. The narration may be accurate about the intended design. The demonstration still hasn't shown it.
The handoff, seen from each seat
The example below is fictional. No account was created, no permission was changed, and no approval was attempted in the writing of this article. Treat it as a script to build against a verified permission matrix, not as a report of something observed.
Stated rules for the fixture. A purchase-request workflow with three roles. A requester can create a request, submit it, and view their own requests — nothing else. An approver can view and approve requests in the Operations department, and nothing outside it. An administrator assigns roles and prepares the fixture, and does not appear in the workflow. The requester is Dana, in Operations. The approver is Priya, also in Operations. The object is a single request: four replacement monitors, $960, cost centre Operations.
Step one — the requester works. Dana signs in. The script shows the signed-in name on screen, because otherwise the audience is guessing. Dana creates the request; it appears as a draft. Dana submits it. The status becomes Submitted, awaiting approval. Dana's list contains her own requests only, and the matrix says her role carries no approval action on any request, including her own. That second part is an expectation until step three puts it to the screen.
Step two — the wait. Nothing happens. The request sits in Submitted until Priya acts. Give this state a beat in the demonstration rather than clicking straight through it, because this is the state the buyer's users will be in at 4:45 on a Friday. If your script implies the approval is instant, you've replaced a workflow fact with a performance.
Step three — the action that shouldn't be available. Dana opens her own request through the ordinary interface and tries to approve it. The request is still Submitted, and that state is the point: a record that has already been approved can't answer this question, because whatever the screen shows for a closed request tells you nothing about the pending-request boundary. Under the declared rules, the requester role has no approval action, including on her own request. What actually appears is something you inspect and record, not something you assert. Three outcomes are possible, and they mean different things:
- No action is offered. Record it as what the screen showed. A missing control is an interface observation. It is not proof that the underlying action is refused, because the service behind the screen might still accept a request the interface never offers.
- The action is offered and fails. Record the exact message.
- The action is offered and succeeds. Then the configured fixture contradicts the permission description, and the remaining steps are running against a fixture that no longer matches its own rules. That's a finding about this configuration, and it needs to be reconciled with the owner before the script is used again. It doesn't tell you anything about the security of anyone's production system.
Notice what step three is not. It's not an intrusion test. You don't reach past the interface, you don't construct a request by hand, and you don't run the same probe across a dozen accounts looking for a break. One ordinary action, attempted through the product's intended interface by an authorized user of that fixture, compared against the written permission description. That's the whole exercise, and a single denied action is not a security assurance. It's a demonstration that the boundary you described produced the behavior you described.
Step four — the approver works. Priya signs in. Her queue shows the Operations request with the requester's name, the department, the amount and the submission time. She approves it. The status becomes Approved, with the approver's name and the time recorded.
If you want the scope boundary to be visible rather than merely stated, add a second requester in Finance and a second request. Priya's queue should not contain it. That one extra account demonstrates the difference between "the approver can approve" and "the approver can approve within her department," which is the part a buyer's own permission design usually hinges on.
Step five — the requester's view changes. Dana signs in again, or refreshes, and sees Approved, with Priya's name and the time. Her list still contains her own requests only, and the approval action is still absent, as it was at step three.
Distinguish a boundary from a fault
Buyers misread restricted actions all the time, and the misreading usually isn't their fault — a greyed-out button looks like a bug if nobody explains it. So explain it in the moment. "She can't approve her own request. That's the rule, not a failure." If instead the product really is misbehaving in your fixture, say that too, and say which it is. An intentionally unavailable action and a broken one can look identical on screen, and the demonstration is the only place the audience can learn the difference.
The same applies to any deliberately narrow configuration. If approvals normally route through a manager hierarchy and your fixture assigns the approver directly, that's a shortcut, and the script should name it where it happens rather than leaving the buyer to discover it in their own implementation. Declared shortcuts are part of an honest demo. Undeclared ones become implementation surprises.
Write down what you configured
A role demonstration has two deliverables: the sequence the audience watched, and the configuration that made it possible. Keep the second one with the script. Which accounts, which roles, which scopes, which fixture data, which shortcuts, and which steps required an administrator beforehand. Azure's principal/definition/scope model is a convenient way to organize that note, though it remains an Azure-specific description and not a claim about how any other product enforces its permissions.
Two habits keep the script reusable. First, always reopen the sequence through the intended accounts. An old privileged session will happily still be signed in, and a browser profile that remembers the administrator is the most common way a carefully built two-role demo quietly collapses back into one. Show the signed-in identity at each step so a stale session becomes visible instead of invisible. Second, treat a change to a role or permission as a change to the script. If the requester role gains a permission or the approver's scope widens, the affected steps need to be reviewed — and in some cases re-observed — before you rely on them again.
And when the environment genuinely can't show a boundary — because the accounts aren't available, or the fixture is configured too broadly to separate the roles — say that. "We couldn't set up a separate requester account for this environment, so this part is unverified" is a survivable sentence in a demo. Borrowing an administrator account to act it out is not, because the audience will remember the workflow and forget the caveat.
Keep the wait
The finished script should read like this: role, action, resulting state, next role's view, observed outcome. The gap between Dana's submission and Priya's approval belongs in the script for the same reason the approval does. It's a state the buyer's users will occupy, and it's evidence about how the product handles work that is waiting on someone else.
You can add an administrator view to the demonstration. Just put it where it belongs — before or after the workflow, explaining setup — rather than threading it through the middle, where it will absorb the ordinary users' work without anyone noticing. What the buyer should leave with is not the impression that the product can do all of this. It's a clear picture of who does what, in what order, and which boundaries they'll be living inside once the demo is over.
Frequently asked questions
Why is it a problem to demonstrate roles using an administrator account?
The audience cannot tell which actions are permissions and which are narration. An administrator account can perform every step, so the demonstration may show an intended design but not the configured boundary. Setup by an administrator should happen before the run and be stated out loud.
What questions should you ask before building a role demonstration?
Ask who is acting, what that identity may do, and over which resources. Get answers in writing as a permission matrix. A job title or role name is not itself a permission. Also ask whether the ordinary-user account holds more than one role assignment or group membership.
What does an absent or failed approval action prove?
If no action is offered, record what the screen showed; it is an interface observation, not proof that the underlying service refuses the action. If the action is offered and fails, record the exact message. If it is offered and succeeds, the fixture contradicts the permission description and must be reconciled before reuse. This is not an intrusion test.
Why keep the waiting state in the demonstration?
The gap between submission and approval is a state real users occupy. Giving it a beat shows how the product handles work waiting on someone else. Clicking straight through replaces a workflow fact with a performance.
What should you do if the environment cannot show a role boundary?
Say so. A sentence such as 'We could not set up a separate requester account for this environment, so this part is unverified' is survivable. Borrowing an administrator account to act it out is not, because the audience will remember the workflow and forget the caveat.