Safe demo environments

The working approach

Separate demo identities from personal accounts.
Limit actions to the intended workflow.
Inspect the footage for secrets before sharing.

Minimise what the recorder can see

Use a demo identity with access limited to the intended task. A fresh browser prevents accidental reuse of personal cookies, but it does not limit the permissions of the account you sign into. Avoid opening billing, credentials or real customer data during exploration. Prepare synthetic examples in advance so the agent does not need to invent sensitive-looking information to make a screen appear realistic.

Review the exported media, not only the source account configuration. Sensitive details can appear in browser chrome, notification banners, URLs or short transitions. Keep private access handling separate from ordinary business-context questions. An email code may be needed to authenticate, but it is not useful marketing context and should not be retained in the visible conversation. Use a clear end condition so the capture environment does not remain active after the task is finished.

A concrete example

Use a synthetic contact such as Alex Example, and avoid opening billing, API credentials or customer exports.

Before recording this scenario, write down what the starting screen contains and what should be different at the end. This gives the reviewer an observable result to check, rather than asking them to approve a general impression.

The mistake to avoid

A new browser alone does not make a production account safe to record.

If the source cannot support the intended message, narrow the claim or capture the missing evidence. A transition, caption or voiceover can explain a real change; it should not manufacture one.

Put it into a production brief

Replace the bracketed fields before using this brief. The scenario is illustrative; keep only the actions your product actually supports.

EDITABLE PRODUCTION BRIEF

Purpose: Safe demo environments.
Audience: [specify the viewer and their familiarity with the product].
Decision: [what should the viewer understand or do next?].
Approach: A dedicated workspace reduces accidental disclosure and makes retakes repeatable. It should contain useful fictional data and narrowly scoped permissions.

Required evidence:
1. Separate demo identities from personal accounts. Show the relevant entry state, action and completed result.
2. Limit actions to the intended workflow. Show the relevant entry state, action and completed result.
3. Inspect the footage for secrets before sharing. Show the relevant entry state, action and completed result.

Reference scenario: Use a synthetic contact such as Alex Example, and avoid opening billing, API credentials or customer exports.
Avoid: A new browser alone does not make a production account safe to record.

Deliverable: [duration], [format], [placement].
Use only recorded product behaviour. Preserve the full original.
Acceptance: check each claim against its visible scene, review at actual viewing size, and test the final file.

Review before delivery

Evidence: can a new viewer identify the result described in the example without being told where to look?
Reading distance: are the relevant controls and labels understandable at the intended placement size?
Continuity: does each cut preserve the relationship between the action and its result?
Accuracy: does the final caption describe the visible product state, including any limits?

Using this with Demovela

The automatic URL workflow currently supports Postraid and Adfolio. Other product scenarios on this page are production-planning examples, not compatibility claims. Adapt the brief to your own recorder or editor. Demovela preserves originals and creates separate outputs; review the resulting file before publishing.

Check the current preview scope →

Keep the workflow moving

Choose the next resource based on the decision you still need to make.

Browse the complete resource library →