Let people evaluate a task with explicit sample-data boundaries and recoverable actions.
A trial interaction lets people understand a capability by using it. Define what the example does, which data it changes, and how to leave or reset it before inviting someone to begin.
Use original sample content that makes the outcome easy to inspect. Label sample data and explain whether changes persist beyond the session. If the task affects real records or sends information elsewhere, describe that consequence before activation.
Do not imply that a demonstration includes a hosted trial, free account, subscription, or commercial offer. Those services and their policies require separate product decisions. The Liquidify playground and component catalog are places to inspect interface examples, not evidence of a commercial trial service.
Choose a small action, such as changing a sample preference or saving a sample filter. Keep the initial configuration understandable and make the result visible. Provide a reset action only when the application can restore the promised starting state.
A Button can initiate the action and show application-controlled loading. It does not isolate sample data, persist changes, or roll back a request. Implement those boundaries in the example's data layer and handlers.
Explain when the action is running and prevent duplicate requests where necessary. If it fails, retain useful input and provide a retry or exit path. A reset or dismissal must not claim to cancel an operation that continues in the background.
Keep real operations separate from the sample task. If someone chooses to continue with their own data, identify that transition and any new requirements. Use Onboard for setup and Forms for submission and recovery.
Verify the stated data boundary, reset behavior, keyboard operation, and result at narrow widths. Check fresh and returning sessions. A successful animation or spinner does not prove that the underlying operation completed.