Vai al contenuto

Automation

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.

Questa pagina non è ancora stata tradotta. Stai leggendo l'originale.

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 and validations, 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.
Suggerimento: 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 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#

GuardRuns onWhenExceptions
Approved orders are lockedUpdate, DeleteStatus (Before) is ApprovedNotes stays editable
Posted invoices can't be deletedDeletePosted is trueFinance managers can bypass
Only managers can close dealsUpdateStatus changed to Won, and the user isn't in Sales managersNone

Status transitions#

A Status column 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.

Sei bloccato o manca qualcosa? Chiedi alla community.

Chiedi alla community

Visualizza come MarkdownSuggerisci un miglioramento