Automations

Workflow reference | REST calls | Expressions | Polling

Workflow Studio includes 20 common automation templates in its Automations sample section. They reuse REST calls, Entra ID Auth, expressions, loops, and named connections. Productivity, Communication, Developer tools, and Operations add configured API presets to the toolbox. Collections and Date & time add portable expression steps.

Choose an execution host

Choose Automate in the toolbar to schedule the current applied workflow or manage saved schedules. The server copies the workflow and Preview input. Later canvas edits leave that saved copy unchanged; delete and recreate a schedule to update its definition or credentials.

Open Automations, directly below Labs in navigation, for the Manage Automations page. Its library shows schedules owned by this browser, with name search and filters for running, scheduled, paused or finished, and attention-needed automations. Status refreshes every 10 seconds while the page is open. Inspect upcoming UTC run times, expand run history to review outcomes and saved output, and use Pause, Enable, Run now, Cancel run, or Delete to manage a schedule. Running schedules must finish or be canceled before deletion. New automation opens Workflow Studio to create and explicitly approve a new schedule.

Template catalog

Replace example identities, repositories, drive IDs, dates, and HTTPS endpoints before running. Microsoft Graph steps use /users/{id} with an Entra auth output and application permissions, allowing unattended execution. The step description names its required permission. Grant only the permissions and mailbox or site access needed by the selected workflow.

Calendar agendas use the next 24 hours. Focus blocks start 30 minutes after each run and last one hour. List operations have explicit limits: 50 mail, calendar, drive, issue, or pull request records; 20 messages for attachment inventory; 20 enrichment records; and 10 onboarding issues. Graph reads with additional pages fail before a partial digest is delivered. GitHub samples intentionally cover the first 50 records. Broaden these workflows with explicit, bounded pagination when needed.

The background-job template submits once, then polls every 10 seconds for at most 60 responses. It stops on completed or failed status, requires completion, and fails if the status remains pending at the iteration bound. Configure both API URLs for your job service.

Email sends depend on Exchange processing after Microsoft Graph accepts the request. Draft templates save drafts for review. Scheduling a write workflow authorizes its configured external changes, including mail, events, folders, mailbox settings, webhooks, and GitHub issues.

Persistent scheduler configuration

The interactive-server app provides /api/workflow-automations and a hosted worker. The scheduler is enabled by default in Development. Enable it explicitly on a secured production host with WorkflowAutomations:Enabled.

Use environment-variable double underscores when configuring a deployed host, for example WorkflowAutomations__Enabled=true and WorkflowAutomations__StoragePath=/data/automations. Mount a persistent volume for that directory and persist the application's Data Protection keys. Existing shared Data Protection configuration applies. Data without its original keys cannot be decrypted.

The host must stay running. A stopped or scaled-to-zero host cannot execute schedules. Deploy replicas against one shared directory and one Data Protection key ring; directory locking and renewable claims coordinate them. Separate local disks create separate scheduler installations.

Schedules support a first UTC time and a fixed interval of 0-525,600 minutes. Zero runs once. Daily is 1,440; weekly is 10,080. UTC intervals retain their UTC timing through daylight saving changes. Missed occurrences coalesce to the next future occurrence, preventing a catch-up burst. Each schedule permits one active run. Pause stops future occurrences; Cancel run requests cancellation of the active operation. Run now explicitly queues one run.

Claims are renewed while work is active. After a host interruption or expired claim, the run is marked Interrupted and its schedule is paused. External actions may already have completed. Review their source systems before enabling or running it again. Interrupted actions are never automatically replayed. Run history retains the latest 20 runs per schedule, with up to 32,768 output characters per run and an explicit truncation indicator.

Credentials and ownership

Saving requires explicit approval to store and execute the workflow unattended. Definitions, input, supplied API keys, service principal credentials, and results are encrypted with ASP.NET Core Data Protection and written atomically. Keep the storage directory private to the application.

Each browser owns its schedules through a random 256-bit management key in LocalStorage. Requests send that key in a same-origin header; API responses omit credential values. Clearing browser storage removes the management key while server schedules continue. Delete schedules before clearing storage, or have a host administrator stop the service and remove the corresponding protected records.

The scheduler uses only explicitly supplied credentials. It never inherits host managed identities or environment secrets. Entra steps require renewable service principal credentials and consented application permissions. Pasted access tokens expire and are unsuitable for recurring work. Session-scoped Lab credentials cannot be saved through the scheduling panel.

Positive pause-on-budget settings and interactive user-input steps require an attending user and are rejected. JIT tools, ACA Sandboxes, and media processing remain available through their existing connected or governed execution paths.

The standalone static or offline PWA exposes the same templates and notification preference. Its scheduling panel explains that persistent execution requires the server-hosted app; browser timers never impersonate a durable scheduler.

Completion notifications

Settings > Operation notifications > Notify after an operation finishes is off by default and persists per browser. Enabling requests browser permission through that explicit action. Completed playground operations, API requests, benchmarks, workflow previews, and opted-in scheduled runs can show a branded Benchius card with the operation name, outcome, elapsed time, dismissal, and a link to review the result.

When browser permission is granted, Benchius also sends an operating system notification with its icon. Denied or unsupported desktop permission retains the in-app completion card and an explanatory settings status. Preview notification demonstrates the experience. Reduced-motion preferences disable the card's arrival animation.

Notifications exclude prompts, credentials, and result contents. Embedded Benchmark and Workflow Studio playgrounds suppress their child alerts so the parent operation reports completion once. Each server schedule has its own completion-alert option; the browser-wide setting remains the final delivery gate. Email and webhook steps operate independently of browser notification preferences.

Keep Benchius open for immediate browser alerts. The server continues scheduled work with the browser closed, and saved completions are checked when Benchius reopens. This feature does not register a Web Push subscription or promise delivery to a closed browser.