Automations

Automations let you define rules that fire automatically when specific events occur — without manual intervention. They are configured once by an admin and then run continuously in the background.

How Automations Work

Event occurs in Aptli
       ↓
System checks all automations for matching trigger
       ↓
Conditions evaluated (if any)
       ↓
Action(s) executed

Automations use an event-driven model. The system does not poll or run on a schedule (for scheduled tasks like nightly alerts, see Work Order notifications below); instead, automations react instantly when the triggering event fires.

Trigger Types

GIS Import Events

Context available:

• job — the import job record (id, filename, fileType, featureCount, status)
• actor — the user who uploaded the file (null for system-initiated imports)

Work Order Events

Report and Validation Events

Project and Task Events

Inventory Events

User Events

Help Request Events

Version and File Events

Scheduled Triggers

Conditions

Conditions narrow when an automation fires. They are evaluated against the event context. Examples:

• job.fileType == 'gdb' — only fire for GDB imports
• workOrder.status == 'completed' — only fire on completion, not cancellation
• actor.email endsWith '@myorg.com' — only fire for internal users
• job.featureCount > 1000 — only fire for large imports

Conditions use a simple expression language. Multiple conditions are ANDed together (all must pass).

Actions

The following action types are available when building automations:

send_notification / send_email

Parameters:

• to — user ID, role name, or creator / assignedTo keywords
• subject — email subject line (supports template variables)
• body — message body (template variables: {{job.filename}}, {{workOrder.name}}, etc.)
• channel — email, push, or both

call_webhook

POST a JSON payload to an external URL.

Parameters:

• url — HTTPS endpoint to call
• headers — optional custom headers (e.g., Authorization)
• includeContext — whether to include the full event context in the payload

Creating an Automation

1. Navigate to Admin → Automations
2. Click New Automation
3. Fill in:
   • Name — descriptive label
   • Trigger — select from the trigger type list
   • Conditions (optional) — add filter expressions
   • Actions — add one or more actions
4. Set Active toggle to enable
5. Click Save

Testing an Automation

From the automation detail page:

1. Click Test Run
2. Select a sample event from recent activity (or paste a JSON context manually)
3. Click Run — the system evaluates conditions and executes actions in a dry-run mode (actions are logged but not actually sent / called)
4. Review the test output for errors

Monitoring

The Automation History tab shows:

• Last 50 executions
• Trigger event that fired it
• Conditions result (pass / skip)
• Action results (success / error per action)
• Timestamp and duration

Failed actions appear in red. Click a row to see the full error.

Best Practices

Start with notifications. The most common use case is sending an alert when a job completes or fails. Test this before building complex chains.

Use conditions liberally. An automation that fires on every event is noisy. Add conditions to target only the situations that matter.

Keep actions idempotent. If an automation fails partway and retries, the actions should be safe to run twice (e.g., send-email is idempotent because a duplicate notification is at worst annoying, not harmful).

Avoid long chains. Automations that trigger other automations are powerful but hard to debug. Document the chain clearly in the automation names and descriptions.

Permissions