> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testdino.com/llms.txt
> Use this file to discover all available pages before exploring further.
# TestDino Actions for Playwright Tests
> Skip, quarantine, or tag Playwright tests from the TestDino dashboard. Rules apply on the next test run, need no code change, and always expire.
TestDino Actions changes how a test behaves without a code change: skip it, quarantine it, or add a tag to its result. You create a rule in the dashboard, and the TestDino CLI applies it inside the Playwright process on your next test run. Find it under **Actions** in the project sidebar.
## Quick Reference
| Question | Answer |
| :-------------------------------------- | :---------------------------------------------------------------- |
| When does a rule take effect? | On the next test run after you save it |
| Does it need a code change or redeploy? | No |
| Can a rule be permanent? | No. Every rule has an expiry date, capped at 365 days |
| Who can create rules? | Organization owners and admins. Members get read access |
| What is required? | `@testdino/playwright` 2.4.0 or later |
| Is a silenced test hidden? | No. Every affected test result carries a chip linking to the rule |
## What each action does
A rule carries 1 or 2 actions. Quarantine and tag can be combined. Skip is exclusive, because a skipped test never produces a result to quarantine or label.
| Action | When it applies | Effect |
| :------------- | :------------------- | :----------------------------------------------------- |
| **Skip** | Before the test runs | The test is not run at all |
| **Quarantine** | After the test runs | It still runs, but a failure will not break your build |
| **Tag only** | After the test runs | It runs as usual, with labels added to the result |
Quarantine changes one thing and one thing only: the CI exit code. TestDino still records the failure as a failure. A quarantined run does not turn green in the dashboard, and status filters on the test runs list stay raw. The run details header shows an amber count of quarantined tests instead.
## Create a rule
Go to **Actions** in the project sidebar and select **Create Actions**. On an empty project the page shows **No rules yet** with a **Create your first rule** button.
Under **Basics**, give the rule a name of up to 200 characters. A reason note is optional and holds up to 1000 characters. It appears in the audit history, so future readers know why the test was silenced.
Pick one of `+1 day`, `+3 days`, `+1 week`, `+30 days`, or choose a date. Expiry is required and cannot be more than 365 days out. When the date passes, the test counts normally again.
Under **Which tests**, add conditions. Each condition is a field, an operator, and one or more values. See [Action rule conditions](/platform/playwright-test-actions/conditions) for the full field and operator reference.
Under **What happens**, pick **Skip**, **Quarantine**, or **Tag only**. Tag mode requires at least 1 tag; quarantine can optionally add tags too.
The form states `Changes take effect on your next test run.` Nothing changes in the run you are currently looking at.
You can also start from a failing test. Open the test case in a test run and create a rule from it, and the form arrives pre-filled with that test's details.
## Rule status
Status is derived from the rule, not set by hand. A manual disable outranks expiry.
| Status | Meaning |
| :--------- | :------------------------------------------------------------- |
| `Active` | In effect on the next test run |
| `Expired` | The expiry date has passed. The rule no longer applies |
| `Disabled` | Turned off by hand. It stays in the list and can be re-enabled |
Filter the Actions list by any of these. Disabling is reversible and keeps the rule's history, so it is the safer choice when you want a rule back later.
## See what a rule affected
Silencing a test does not hide it. Two views answer what a rule has done.
| View | What it shows |
| :--------------------------- | :-------------------------------------------------------------- |
| Affected tests, per rule | Every test case this specific rule touched, grouped by test run |
| Affected tests, project-wide | Every test carrying an action trace, across all rules |
Individual test results carry a chip naming the rule that touched them, on both the test run details page and the test case view. A test run that had tests skipped by a rule lists them on the run details page.
## Audit history
Every rule keeps an append-only event log: `created`, `updated`, `disabled`, `enabled`, and `deleted`. Each event records who did it and when.
Deleting a rule removes the rule, not its history. The `deleted` event embeds a final snapshot of what the rule said, and action traces already recorded on past test results survive as well. "Who silenced this test, and what did the rule match?" stays answerable after the rule is gone.
## Permissions
Creating, editing, enabling, disabling, and deleting a rule requires an organization owner or admin role. Members can read rules and their affected tests. This uses the existing organization role model, so there is no separate permission to grant.
## Requirements
Rules are applied by the CLI at run time, so the reporter has to be recent enough to fetch and apply them.
```bash theme={null}
npm install @testdino/playwright@latest
```
If the CLI cannot reach TestDino when a test run starts, it proceeds with no rules rather than blocking your run. A rules fetch never fails or delays CI.
## Related
Every field and operator you can match on, and the limits that apply.
Create and manage rules over the public REST API.