NirmaanOne Help
TroubleshootingReviewed 2026-09-29

Run errored or blocked with "permission_revoked": the rule's owner no longer holds a permission its actions need

A rule's automatic runs act as the person who last saved or switched the rule, and manual runs as the person who pressed the button; each action is checked against that person's permissions when it runs, so a role change or a deactivated user makes the run fail until the permission is restored or someone who holds it takes the rule over.

Messages this explains

  • “permission_revoked: the acting user no longer holds <perms>”
  • “<ACTION> failed: permission_revoked: the acting user no longer holds <perms>”
  • “actions[<n>]: <OP> needs <PERMS>”
  • “You do not have permission to do that.”
  • “You lack the permission it needs: <code>”
  • “You lack the permissions it needs: <codes>”
  • “You can see this workflow but lack the permission to start it (WORKFLOW_RUNS:create).”
  • “This run was blocked: the rule's owner no longer holds a permission the actions need, or the engine refused to continue.”
  • “Blocked: missing permissions”
  • “Missing: <codes>”
  • “Only errored runs can be retried.”
  • “This rule is inactive.”

Run errored or blocked with "permission_revoked": the rule's owner no longer holds a permission its actions need

A rule that used to work now fails every time, often right after someone's role changed or a user left; or you can't switch a rule, save it, or start it from a record, because of a permission.

What you see

On Runs. On Runs the rule's runs are Errored. The run panel's red box reads "<ACTION> failed: permission_revoked: the acting user no longer holds <perms>", and the action in the Actions list reads "permission_revoked: the acting user no longer holds <perms>", where <perms> lists the missing permissions by module and action (for example the Create permission on Tasks). Tasks, updates or other changes the rule used to make stop appearing; notifications that come after the failed action in the rule stop arriving in the bell (see Sidebar, top bar and notifications bell). A Blocked run without details shows "This run was blocked: the rule's owner no longer holds a permission the actions need, or the engine refused to continue."

In the Test dialog. Test on the rule (from Rules or the Rule page) shows the action as "Blocked: missing permissions" with "Missing: <codes>". These are the permissions the rule's owner lacks.

Switching or saving a rule. Turning the Active switch on the Rules list, or Switch on / Switch off on a system rule, fails with "You do not have permission to do that." Saving the rule shows "actions[<n>]: <OP> needs <PERMS>" in the red banner.

Starting a manual rule from a record. In the Workflows menu on a booking, payment, opportunity, estimate, commission or demand page, a rule you can't start shows a ban icon; choosing it explains "You lack the permission it needs: <code>" (or "You lack the permissions it needs: <codes>"). The run dialog may say "You can see this workflow but lack the permission to start it (WORKFLOW_RUNS:create)."

Retrying. Retry in the run panel can answer "Only errored runs can be retried." or "This rule is inactive."

Why it happens

A rule does things the way a person would, and it is never allowed to do more than a person could. So every run acts as someone:

  • Automatic runs (on create, on update, on an event, on a schedule) act as the rule's owner: the person who last saved it or switched it on or off. For the rules that come with a new organization, that is the administrator who set it up, until someone else switches or clones them.
  • Manual runs act as the person who pressed the button.

Just before each action, the engine checks that this person is still an active user and still holds the permission the action needs: for example the Create permission on Tasks for Create task, the Edit permission on the record's module for Update field, or the Create and Issue permissions on Demands for Create demand run with "Issue the demands at once". If the person was deactivated, or their role (each user has one) no longer grants it, the action fails with "permission_revoked" and the run stops. Actions that need no permission, such as Notify users, Send email and Call webhook, still run if they come first.

The same rule applies when the rule is saved or switched: whoever does it must hold every permission its actions need, because they become its owner. Switching a rule off counts too. Starting a manual rule needs those permissions plus the Create permission on Workflow Runs. Test shows what the current owner is missing.

How to fix it

Choose one of the first two fixes, then retry.

  1. Give the permission back. On Roles & Permissions, open the owner's role in Edit role, tick the missing permission (the code in the message names the module and the action, for example the Create permission on Tasks) and click Save role; or, if the owner was deactivated by mistake, Reactivate them on Users. This needs the Edit permission on Roles & Permissions or on Users; in the default roles only the Administrator has them.
  2. Or take the rule over. Someone who holds every permission the rule's actions need (an Administrator always does) switches the rule off and on again with the Active switch on Rules, or Switch off and Switch on on a system rule's page, or opens the rule and clicks Save changes after a change. They become the owner, and future runs act as them. This needs the Edit permission on Workflow Rules. Use Test on a record afterwards: no action should read "Blocked: missing permissions".
  3. Retry the failed runs. Open each Errored run on Runs and press Retry (the Edit permission on Workflow Runs). The retry of an automatic run acts as the rule's owner now; the retry of a run started by hand still acts as the person who pressed the button. It resumes at the first action that didn't finish. If you see "This rule is inactive.", switch the rule on first; "Only errored runs can be retried." means the run was already retried or is no longer Errored.
  4. For a manual rule you can't start, ask your administrator for the permissions listed in the dialog, or ask someone who holds them to press the button. The code in the dialog's message is the Create permission on Workflow Runs, which only the Administrator holds in the default roles. If the dialog says the record doesn't meet the rule's conditions instead, see "This workflow cannot run right now".
  5. To switch off a rule you don't have the permissions for, ask an Administrator: switching off also checks the permissions its actions need.

Before deactivating a user or changing their role, check the rules they own (the Created by column on Rules shows who made each one; the owner is whoever changed it last) and take them over as in step 2.

Related

  • RunsScreen

    Every time a rule ran: what started it, which record it worked on, how each action went, and the panel from which an errored run is retried.

  • RuleScreen

    One automation rule's page: read or change its basics, trigger, conditions and actions, test it against a record, clone or delete it, and switch a system rule on or off.

  • RulesScreen

    Every automation rule in your organization, system and custom, with filters, the switch that turns each rule on or off, and shortcuts to edit, test, clone, see the run history of or delete a rule.

  • Sidebar, top bar and notifications bellScreen

    The frame around every page once you are signed in: the sidebar with its groups, the top bar with the notifications bell, the light and dark switch and your account menu, and the banners that ask you to act.

  • Roles & PermissionsScreen

    The list of your organization's roles: open one, create or clone a role, deactivate or reactivate it, and delete custom roles nobody holds.

  • Edit roleScreen

    Change a role's name, description, active flag and permissions, see who holds it, and open its History.

  • UsersScreen

    The people in your organization: invite new users, change their role, deactivate or reactivate them, reset a lost two-factor authentication, and resend or revoke pending invitations.

  • A run's action errored: webhook refused, empty role, empty reason, unpublished template or the chain ran too deepTroubleshooting

    A workflow run stops as Errored when one of its actions fails: the webhook address is internal or the other system refused the call, the role to assign to has no active members, a cancellation or lost reason came out blank, or the document template is not published; a run is Blocked when a chain of rules emitting events runs deeper than the engine allows.

  • Workflow rule will not save: a trigger, schedule, condition or action is incomplete or not allowedTroubleshooting

    Create rule or Save changes is refused when the trigger is missing its event type, schedule or input form, when a condition names a field the record doesn't have, when an action is switched off on this server or is set up in a way the engine doesn't allow, or when the rule has nothing to do.

  • "This workflow cannot run right now": the record, the rule or its inputs do not qualifyTroubleshooting

    A manual workflow from a record page's Workflows menu refuses to start because the record no longer meets the rule's conditions, the rule was switched off, changed or moved to another project, or a value in its small form is missing or out of range.

  • Workflow runs and the outboxConcept

    How a change becomes automation: the outbox event written with the change, the pick-up that hands it to the engine, one run per listening rule with a recorded result per action, the statuses each passes through, and how Errored runs are retried and Failed events requeued.

  • Workflow rules, conditions, actions and the rule ownerConcept

    What a workflow rule is made of (one kind of record, one trigger, conditions, ordered actions, an optional chained event), how conditions and action settings are evaluated, how versions, tests and clones work, and why every rule has an owner whose permissions its runs use.

  • System rules and starter templatesConcept

    The 53 automation rules, six email templates and six draft document templates every organization starts with: which ship switched on, why the customer-facing ones ship off, what is locked, and how to switch, clone or customise them.

  • Roles and permissionsConcept

    What a permission is (a module plus an action), how roles bundle permissions, the twelve default roles and what each is meant for, the one-role-per-user rule, and when a change reaches a signed-in user.