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 configuration docid\ r6vgf6m3d k8slkyopppp 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 appeals docid\ hadsvd38gpyc7canb4oyi 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 reporting docid\ ncsbihsujuk1eaeey bh2 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 responses docid b072vnucwf5vbqhvwjqx