# Guard rules

> A guard rule blocks a change outright based on the record's state or the user's role. Learn how to lock approved records and allow exceptions.

A guard refuses a change when its conditions hold. The person sees one clear message and nothing is saved. Use a guard when the change itself isn't allowed, whatever the values are: editing an approved order, deleting a posted invoice, changing a price after shipping.

A guard runs last, after [computations](/docs/business-rules/computation) and [validations](/docs/business-rules/validation), so it sees the final values of the record.

## Create a guard

1. Open any view on the table, click **Settings**, choose **Business Rules**, and click **New rule**.
2. Enter a **Name**, such as "Approved orders are locked", and set the **Rule type** to **Guard**.
3. Under **Runs on**, choose the operations to block, for example **Update** and **Delete**.
4. Under **When**, add the conditions that make the change forbidden, for example "Status is Approved". Use **Field** with **Before** to test the value the record had before this change.
5. Enter the **Message shown to the user**, such as "This order is approved and can no longer be changed."
6. Optionally choose **Fields that stay editable** and **Groups that can bypass**.
7. Click **Create rule**.

> **Tip:** To lock a record once it reaches a state, test the value **Before** the change. Testing the value after the change would also block the change that moves the record into that state.

## Fields that stay editable

A locked record often still needs a few fields to change, such as internal notes or a tracking number. Add them under **Fields that stay editable**. An update that only touches those fields passes the guard.

## Groups that can bypass

Add [groups](/docs/groups) under **Groups that can bypass** to let their members make the change anyway, for example a "Finance managers" group that can correct posted invoices. Organization owners can always bypass a guard. If the list is empty, nobody else can.

## Examples

| Guard | Runs on | When | Exceptions |
| --- | --- | --- | --- |
| Approved orders are locked | Update, Delete | Status (Before) is Approved | Notes stays editable |
| Posted invoices can't be deleted | Delete | Posted is true | Finance managers can bypass |
| Only managers can close deals | Update | Status changed to Won, and the user isn't in Sales managers | None |

## Status transitions

A [Status column](/docs/columns/status) can already limit which moves are allowed between states. You don't need a guard for that. Add a guard when you also need a custom message or an exception for certain groups.

  - [Business rules](/docs/business-rules): How the rule types fit together and run.
  - [Validation](/docs/business-rules/validation): Check data and show what is wrong.
  - [Groups](/docs/groups): Organize members for permissions and exceptions.

---

Source: https://community.sapugo.app/docs/business-rules/guard