Automation
Playground
Test workflow templates and scripts without publishing them to live records or tickets.
Playground
Playground covers safe testing for automation templates, scripts, triggers, Iris nodes, and sample payloads before publishing. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: safe testing for automation templates, scripts, triggers, Iris nodes, and sample payloads before publishing.
- Where users start: Automation playground routes are
/automation/playgroundand/automation/playground/:playgroundId/view. - Where administrators configure it: Object script playground routes use
/settings/objects/:objectId/scripts/:scriptId/playground. - Runtime/detail surface: Playground runs reveal inputs, outputs, errors, and side effects before a workflow or script affects real users.
- Platform connections: Playground connects Workflow Studio, object scripts, trigger payloads, Iris prompts, webhook tests, and automation logs.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Automation playground routes are /automation/playground and /automation/playground/:playgroundId/view. | Day-to-day work and review. |
| Configuration | Object script playground routes use /settings/objects/:objectId/scripts/:scriptId/playground. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Playground runs reveal inputs, outputs, errors, and side effects before a workflow or script affects real users. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Automation playground routes are
/automation/playgroundand/automation/playground/:playgroundId/view. - Review the configuration route and permissions before changing live behaviour: Object script playground routes use
/settings/objects/:objectId/scripts/:scriptId/playground. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Automation playground, Script playground, and Sample payload first because they shape the rest of the rollout.
- Add Failure run and Iris prompt test only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Playground runs reveal inputs, outputs, errors, and side effects before a workflow or script affects real users.
- Check downstream connections after saving: Playground connects Workflow Studio, object scripts, trigger payloads, Iris prompts, webhook tests, and automation logs.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Automation playground | A workflow or automation needs test data | Route: /automation/playground. |
| Script playground | An object script needs execution checks | Route: /settings/objects/:objectId/scripts/:scriptId/playground. |
| Sample payload | A trigger event must be inspected | Use representative object, task, or ticket data. |
| Failure run | A branch or exception should be tested | Confirm logs are readable. |
| Iris prompt test | An AI node needs predictable output | Keep prompt and context narrow. |
| Regression test | A published process is being changed | Re-run old and new scenarios. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Automation playground and Script playground.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.