Triggers from across the platform
Supported product events, schedules, inbound webhooks, and authorized manual launches can start a tenant-scoped workflow.
Workflow Automation
Automate repeatable work with a clear stop and recovery path.
Explore rules that connect a trigger to the right customer, action and approver. Start with one routine task, then check duplicate handling, retries and the result before expanding.
A change you can inspect
Move from current state to a controlled next step.
Inspect the illustrative workflow map
Deterministic workflow automation
Trigger, decision, approval, action, retry, and outcomeDeterministic workflow pathRule controlled
SignalSource attached
Scope checkPolicy applied
Rule matchDefined condition
Action gatePolicy decision
Versioned conditionsRetry boundedRollback defined
Dayrook · illustrative workflow preview
See one signal move all the way to proof.
Choose a common MSP workflow, then step through the policy, ownership, action, and verification Dayrook keeps connected.
Endpoint operations → service operations
A security update needs a controlled rollout.
- 01SignalUpdate detectedDone
Affected devices and current versions are identified.
- 02PolicyScope evaluatedDone
Client policy, maintenance window, risk, and reboot rules are checked.
- 03ApprovalWave approvedDone
The permitted ring and recovery conditions are confirmed.
- 04ActionPatch executedDone
Endpoint operations run the bounded deployment and verify the result.
- 05ProofEvidence attachedNow
Outcome, exceptions, owner, and timestamps return to the client record.
Automate the repeatable path without bypassing the decision gates.
Connect supported events, schedules, webhooks, and manual runs to governed multi-step workflows.
Make approvals, retries, compensation, dead letters, recovery, and evidence visible to operators.
Inside the workflow
The work this connects.
- Flexible triggers
- Use product events, cron schedules, inbound webhooks, and manual launches within tenant scope.
- Conditional workflows
- Combine nested AND and OR conditions with customer, device, policy, severity, time, entitlement, and state context.
- Cross-module actions
- Create tickets, run scripts, update fields, notify teams, dispatch webhooks, start backups, and call supported provider workflows.
- Approval routing
- Pause sensitive steps for the right separate approver and revalidate the exact request before execution.
- Reliable orchestration
- Use durable step state, dependencies, bounded backoff, replay-safe identities, and a visible dead-letter queue.
- Execution history
- Review each decision, step, attempt, provider response class, verification result, and final outcome.
Try one useful scenario
A duplicate event and a denied action
Fictional workflow: receive event E-42 twice. Match both deliveries to one incident, propose one change and request approval. The approver denies it; no mutation should run. Exercise record: 09:00 E-42 arrives; 09:01 its duplicate is recorded; service owner Alex owns ticket T-42; 09:03 approval is denied. No write is attempted and the response timer continues under the example policy. A separate read-only verification times out twice, reaches its two-retry ceiling and escalates to Alex. Aborting cancels pending work; any compensation requires a separately authorized action and evidence.
Illustrative evaluation scenario, not a recorded product result.What a useful result must show
The evaluator checks a single incident, the duplicate record, the denial, zero provider changes and bounded retries. A changed target requires fresh authorization.
Get the evaluation worksheet →Check the support boundaries
- Supported triggers and conditions
- Action adapters and permission scope
- Idempotency retention and retry ceilings
- Approval expiry, replay and compensation
Workflow Automation follows defined conditions and actions. Assist interprets a request and proposes a plan. Both need an authorized executor and post-action evidence; replay and compensation are not universal rollback.
Check public evidence and availability →Scope, availability and evaluation details
Only published triggers, conditions, and actions are available.
Automation cannot bypass tenant, region, role, entitlement, approval, provider, or local-agent policy.
The proposed $99 monthly model includes the target product scope for evaluation, unlimited technicians, unlimited customers, and the first 50 managed devices. Final terms require confirmation. See transparent pricing →
Review full environment and integration scope
Actions stay with their owner
Ticket, script, notification, webhook, backup, and provider steps call the owning module, preserving its permissions, secrets, approvals, regional routing, idempotency, result verification, retry, and dead-letter behavior.
Automation calls the owning module or provider integration; it does not duplicate its permissions, credentials, or business rules.
Questions, answered
Before you choose your next step.
What can trigger a workflow?
Supported product events, schedules, webhooks, and authorized manual runs can start a workflow.
Can automation run scripts on endpoints?
Yes, when the script, device, policy, permission, local agent, and approval requirements all pass at execution time.
What happens when a step fails?
Retryable failures use bounded backoff. Terminal failures remain visible with their last safe state, evidence, and manual retry or dead-letter path.
Can an automated workflow perform a high-risk action?
Only through the same step-up and separate-approval controls that govern the action when launched manually.