Figure 1. Community Automations rule list in the Admin panel.

1. Overview

Orchestrator (Community Automations) lets administrators configure rule-based workflows that respond to specific events in the community. Each rule follows a simple logic pattern: when a trigger occurs, the system checks any configured conditions and then executes the selected actions.

• Use orchestrator to streamline repetitive admin work.
• Apply actions only when the defined criteria match.
• Combine business rules with community events such as registration, role assignment, group joins, and topic activity.
• Configure one or more actions per rule.

2. Accessing the tool

In the admin settings, navigate to: Admin Panel → System → Community Automation.

From the Orchestrator landing page, admins can see whether rules are enabled, review existing rules, and create a new rule from the Create Rule button in the upper-right area of the page.

Figure 2. Community Automations landing page showing existing rules and the Create Rule entry point.

3. Creating a rule

To create a rule, open the Create Rule form and complete the key sections shown in the builder.

 

Figure 3. Create Rule form with name, description, enable toggle, trigger, conditions, and Create action.

4. Rule builder anatomy

5. Available triggers

Triggers are the events that initiate a rule. Once a trigger occurs, Orchestrator checks the configured conditions and executes the actions if the rule criteria are satisfied.

Figure 4. Trigger selector showing the currently available trigger options.

6. Conditions and operators

Conditions are optional. Use them when a rule should run only for a subset of users, boards, or groups. The current UI supports the operators Equal To and Not Equal To.

Figure 5. Example of conditions using Role and Email Domain, with an AND connector and the condition type dropdown.

Guidance for using conditions:

• Use Email Domain to separate internal users from external users.
• Use Role when actions should apply only to members with a known entitlement or status.
• Use Group when approving or messaging should be scoped to a specific community group.
• Use Board when a content-related automation should apply only in a particular board or forum.

7. Available actions

Actions determine what the system does when the trigger occurs, and the conditions match. A rule can include more than one action.

Figure 6. Action picker showing the currently available action types.

8. Action configuration details

Assign Roles

Use this action to automatically add one or more roles to a user when the rule criteria are met. This is useful for onboarding, entitlement mapping, or permission management.

Figure 7. Assign Roles action configured with multiple target roles.

Call Webhook

Use this action to notify an external system by sending an HTTP request to a configured endpoint. The UI supports a destination URL and optional custom request headers.

Figure 8. Call Webhook action with endpoint URL and optional custom headers.

How it works

The Call Webhook action pushes event data from the community to any external system that can receive HTTP requests. Common use cases include sending notifications to Slack or Microsoft Teams, logging events to an audit system, triggering workflows in automation platforms (such as Zapier or Make), and syncing data with a CRM, ticketing system, or internal tool.

When the rule fires, Orchestrator sends an HTTP POST request to your configured URL. The request body contains a JSON payload with details about the event that triggered the rule, such as the user involved, the board, topic title, and any other relevant context.

Configuration fields

The Call Webhook action has three parts in the UI:

• Destination URL: The full HTTPS endpoint where the request will be sent (e.g., https://hooks.slack.com/services/T00/B00/xxxx).
• Test Endpoint button: Sends a test request to verify the URL is reachable and responding correctly before the rule goes live.
• Custom Headers (Optional): Key-value pairs added to the HTTP request headers. Use these for authentication tokens, content-type overrides, or any custom metadata your receiving system requires.

Step-by-step: Setting up a webhook action

• Create or edit a rule and select the trigger and conditions you need
• In the “Then…” section, click Add Action and select “Call Webhook” from the dropdown.
• Enter the destination URL. Paste the full endpoint URL provided by your external system. This must be an HTTPS URL.
• Add custom headers if required. Click “+ Add Header” to add each header as a key-value pair (see examples below).
• Click “Test Endpoint” to confirm the external system receives the request successfully.
• Save the rule. Once created and enabled, the webhook will fire every time the trigger and conditions are met.

Example: Sending a Slack notification when a new topic is posted in a particular/any board

Slack Incoming Webhooks let external applications post messages directly into a Slack channel. You create a webhook URL inside Slack, and any HTTP POST request sent to that URL appears as a message in the channel you chose.

How to get your Slack webhook URL:

• Go to api.slack.com/apps and create a new Slack App (or select an existing one).
• In the left sidebar, go to Features → Incoming Webhooks and toggle it to On.
• Click Add New Webhook to Workspace and select the channel where you want alerts posted (e.g., #community-alerts).
• Slack generates a unique URL in this format: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
• Copy this URL - you will paste it into the Orchestrator webhook Destination URL field.

Note: Treat this URL like a password. Anyone who has it can post messages to your Slack channel. Do not share it publicly.

Send Private Message

Use this action to send an in-community private message. The UI supports recipients, subject, body, and event variables for dynamic content.

Figure 9. Send Private Message action with available event variables.

Send Email

Use this action to send an email notification. The UI supports To, Subject, Message, content format selection, and event variables for personalization.

Figure 10. Send Email action showing recipient, subject, message, and available variables.

Approve Request

Use this action to automatically approve a pending request when the rule criteria are satisfied. This is especially useful for group join workflows where qualified users should be approved immediately.

9. Using variables in email and message content

The Send Email and Send Private Message screens display the event variables that can be inserted into the message content. Based on the current UI, the following variables are available in the examples shown:

Use variables to make messages more relevant and reduce manual follow-up. For example, you can address the user by name, reference the group involved, or include the request date in an approval notification.

The available variables panel updates dynamically based on the selected trigger. User lifecycle triggers expose user-related variables, group-related triggers add {NODE_NAME} and {REQUEST_DATE}, content triggers expose topic-related variables, and the Clarification Nudge Requested trigger exposes the question/topic that needs clarification.

10. Example rule patterns

11. Admin best practices

• Use clear rule names and add a simple description so other administrators can understand the purpose.
• Keep triggers broad and use conditions to narrow the scope when needed.
• Avoid overlapping rules that may send duplicate messages or assign duplicate roles.
• Document external webhook destinations and business owners before enabling production rules.
• Review message content carefully when using variables so recipient-facing communications read naturally. Always preview before enabling the rule.
• Start with a small, specific rule before expanding automation coverage.
• Leverage the "Not Equal To" operator for exclusion-based rules (e.g., "Role Not Equal To Admin") when it's simpler than listing every role you want to include.
•