Actions
Actions are the outcomes that Nima triggers on your platform.
By configuring actions, you can ensure that any desired outcome is executed on your platform.
In Nima, actions are classified in 3 main categories:
- Moderation Actions to enforce outcomes linked to your policies, such as 'block content' after a policy violation.
- Workflow Actions to support operational tasks without enforcing policies, such as 'unblock user'.
- Revert Actions to allow moderators to undo previous actions after a case has been processed.
Moderation actions
Moderation Actions are the core enforcement mechanism in Nima.
Each moderation action is pre-configured and linked to a specific policy. When a policy is applied - either through automated or human moderation - Nima automatically triggers the associated action.
These actions translate policy decisions into concrete outcomes for:
- content, such as removing it, restricting its visibility, blurring, annotating, or marking it as sensitive
- a user, such as issuing warnings, suspensions, or bans .
How to set up moderation actions for policies? You can map your policies or sub-policies to a single Moderation Action in Policy ConfigurationPolicy Configuration.
While policies determine what is allowed or not on your platform, Moderation Actions determine what happens when a policy is enforced.
Moderation actions will be directly selectable by moderators when reviewing appeals, as detailed in AppealsAppeals.
Workflow actions
Workflow Actions are used to manage moderation workflows and do not enforce policies.
They support operational activities such as quality assurance, secondary reviews, or reversing a previous enforcement (for example, unlocking content or restoring a user account).
Workflow actions are created in Configure > Trust & Safety > Actions, on the Workflow Actions tab. Because they are not linked to policies, you then choose which of them each queue can use: open the queue and select them under Assign Decision Actions to This Queue.
This ensures that operational actions are contextual, visible only where needed, and never bypass Nima’s policy-centric enforcement model.
Revert Actions
Revert actions allow moderators to undo enforcement decisions after a case has been processed. This supports quality control workflows where mismatched decisions need to be corrected with user notification.
When configuring a revert action:
- Create a new action in Configure > Trust & Safety > Actions > Revert Actions
- Click on 'New Action' and give it a name.
- Configure the webhook to undo the enforcement on your platform (e.g., restore content, unban user)
- Optionally assign a notification template to inform the affected user
Revert actions can only be applied to cases that have already been processed. They appear in the Revert Action selector in the Moderation Console when viewing processed cases.
When a revert action is applied, moderators can toggle the Previous Decision panel in the Action Taken section to see the original action, policy, and sub-policy that was overridden, providing full audit context for quality control reviews.
Configuring actions
All actions are configured in Configure > Trust & Safety > Actions. As you add an action, you can define:
- Action Parameters to select the type of action.
- Post Endpoint URL to connect a webhook so that when Nima triggers an action, the decision is reflected on your platform in real-time - this is critical to make sure actions executed in Nima are reflected on your platform.
- Alias: a user-friendly display name shown on the Enforcement Portal. Defaults to the action name and can be customized to make enforcement outcomes clearer to end users.
- DSA Action Categories to map the action to a specific DSA category (e.g., removal, disabling access, demonetisation) to ensure full coverage in DSA DSA Transparency ReportingTransparency Reporting
Connecting an action to your platform
An action decides what should happen. The webhook is what actually makes it happen on your side — without one, Nima records the decision but nothing changes on your platform. Treat the endpoint as the integration, not as an optional field.
When you configure an action:
- Post Endpoint URL — the endpoint on your platform that Nima calls when the action is triggered. It should carry out the enforcement (remove the content, suspend the account) and return a response Nima can interpret.
- Authorized Header Key and Authorized Header Value — an optional header sent with every call, so your endpoint can authenticate that the request came from Nima. Use these if your endpoint is protected rather than opening it up.
Nima records whether each call succeeded, so a misconfigured or unreachable endpoint surfaces as a failed action rather than failing silently. For the response format Nima expects and how failures are retried, see Understanding webhook responsesUnderstanding webhook responses.
