Loading workspace...
Auroranexis documentation
Automation turns operational events into repeatable workflows your agency can trust. Define triggers, apply conditions, chain actions, and review execution history when something needs attention. Connect external systems through Automation → Connectors and store API credentials at Integrations → Secrets. The automation builder is plan-gated—confirm your subscription includes workflow access in Settings → Billing before building production automations.
The Automation module is your agency's workflow engine inside Auroranexis. When something happens in the platform—a report is published, an incident is created, an SLA threshold is crossed, or a client record changes—automation can respond with notifications, internal updates, or calls to connected systems.
Workflows are organization-scoped. Only users with workflow permissions can create or edit them. Each workflow has a status (draft, active, or disabled), a single trigger, optional conditions, and one or more actions executed in sequence. The workflow list shows status, last execution time, and recent failure counts so operators can spot problems quickly.
Connector-backed actions require authorized connections at Automation → Connectors and, where applicable, stored credentials at Integrations → Secrets. Execution history records every run with step-level detail—the audit trail you need for troubleshooting, client reviews, and compliance discussions.
Agencies manage dozens of clients and hundreds of operational signals. Manual follow-up does not scale. Automation reduces repetitive work, enforces consistent response patterns, and keeps external systems in sync without requiring your team to copy data between tools.
Well-designed workflows complement human judgment rather than replacing it. They handle predictable reactions—notify the account owner, log an activity, open a ticket—so your team can focus on client conversations, root-cause analysis, and delivery quality.
Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.
Workflow status reference
| Status | Behavior |
|---|---|
| Draft | Editable; does not respond to triggers. |
| Active | Listens for trigger events and runs actions. |
| Disabled | Preserved but inactive; no new executions. |
A workflow is a named definition consisting of a trigger, optional conditions, and actions. Workflows move through draft → active → disabled. Only active workflows respond to platform events. Disabled workflows are preserved for history but do not execute.
The trigger is the event that starts a workflow run. Common triggers include client created, incident created or updated, report published, risk created, SLA warning or breached, monitoring event detected, and manual trigger for on-demand testing. Each workflow has exactly one trigger—create separate workflows for separate events.
Conditions filter which events actually run the workflow. Match on severity, client, owner, SLA status, tags, and other fields using equals, contains, greater than, and similar operators. Condition groups support AND/OR logic so high-volume triggers do not flood your team or external systems.
Assign a workflow owner on your operations team responsible for reviewing execution history and updating conditions when delivery playbooks change. This role pairs naturally with integration administration in the Automation area.
A digital marketing agency on Professional connects HubSpot at Automation → Connectors. When a monthly performance report is published for a retainer client, a workflow sends a Slack message to the account channel and logs a HubSpot activity with the report title. Conditions limit execution to Active clients with a specific tag. Execution history confirms each delivery before the account manager emails the client.
An AI automation consultancy builds workflows triggered on incident created with condition severity equals high. Actions create a Linear ticket with the incident summary, assign the client owner internally, and send notification to the on-call engineer. A second workflow on SLA breached posts to a Teams channel for leadership visibility. Secrets for a custom webhook endpoint are stored at Integrations → Secrets.
A managed services provider monitors dozens of clients. Workflows on monitoring event detected with condition severity equals critical create incidents automatically, notify the assigned owner, and open Zendesk tickets for the NOC queue. A separate workflow on report published ensures QBR deliverables trigger client-owner notifications without manual polling of the Reports module.
A strategy consultancy uses lighter automation: report published triggers send notification to the engagement lead and create activity on the client timeline. Risk created with high severity assigns the partner of record. The team reviews execution history monthly rather than daily because external write volume is low and notifications are the primary outcome.
An enterprise agency with custom plan limits runs tiered workflows per client segment. Premium clients get immediate Jira escalation on SLA breach; standard clients get notification only. Workflow permissions are restricted to admins; staff can view execution history but not edit definitions. OAuth connectors are authorized once per workspace with secrets rotated quarterly per security policy.
Automation troubleshooting
| Problem | Cause | Solution |
|---|---|---|
| Workflow not firing | Status is Draft or Disabled, or conditions are too narrow. | Set status to Active; verify the trigger event occurred; review and broaden conditions. |
| Execution failed on connector action | Expired OAuth token or revoked provider consent. | Reconnect at Automation → Connectors; confirm the provider account still has required permissions. |
| Execution failed on secret-based action | API key rotated or revoked at the provider. | Update the value at Integrations → Secrets; rerun with manual trigger to confirm. |
| Duplicate external tickets or messages | Multiple active workflows share the same trigger without exclusive conditions. | Consolidate workflows or add mutually exclusive conditions; prefer created over updated triggers. |
Actions are the steps executed after a trigger fires and conditions pass. Built-in actions include send notification, create activity, assign owner, update record fields, and AI-assisted summaries where your plan includes them. Connector-backed actions—such as create Jira issue or send Slack message—require an authorized connection at Automation → Connectors.
Each time a workflow runs, an execution record is created with a timestamp, status (success, failed, or partial), and per-step detail. Open execution history on the workflow detail page to see which step failed and why. Export execution logs when you need an offline record for post-incident review.
Automation → Connectors holds OAuth-linked external systems used as workflow action targets. Integrations → Secrets stores API keys or tokens for integrations that require manual credential entry. Secrets are encrypted at rest and referenced at runtime. Rotate secrets on your security schedule and update stored values before revoking old credentials at the provider.
| Automation module not visible | Plan does not include the builder or role lacks workflow permissions. | Upgrade via Settings → Billing; ask a workspace owner to verify role permissions. |
| Partial execution status | One action succeeded but a later step failed. | Open execution detail for the failing step; fix connector or secret; earlier steps may need manual cleanup externally. |
| High execution volume after import | Bulk data changes fired many trigger events. | Disable affected workflows before imports; re-enable after validating execution history. |
