Automate with workflows

Automation in My Apps lets you build a workflow once and have it prepare changes for you: for example, disable a leaver’s account and, only after that is verified, revoke their AI keys. A workflow never skips approval. Every step that changes something is sent to the app that owns it, people approve it in that app, and the app does the change and checks the result.

What a workflow is made of

Steps are laid out top to bottom, each with one color.

Step	What it does
Trigger	When it starts: a person starts it, a schedule, a new finding in any app, a certificate or secret that is expiring, or a backup that failed.
Condition	A Yes/No question about the trigger or an earlier step, such as severity is high, or cost is more than $100.
Action	A change in an app. It shows the app, a plain title, the risk and the permission you need.
Approval	Always placed before an action. It can only add people on top of the app’s own rules.
Notify	An e-mail, or a Teams or Slack message if an administrator set that up.
Wait	Pause for a while.
End	Finish.

Approval is always required

• Add an Action and its Approval step appears with it. You can’t remove the approval on its own, and a workflow without it can’t be published.
• The app’s own rules always apply: a different person approves (never the person who asked), and high and critical changes need two people, each with a fresh authenticator check. The Approval step can add people who must sign off first, and a time limit. If nobody answers in time the workflow stops; it never carries on without approval.
• A workflow never approves anything, for anyone.

Build one

1. Open Automation and choose a template (new joiner, leaver, disk almost full, failed backup twice, expiring certificate or secret, unused cloud resource), or type what you want under Describe it to Vision and choose Build a draft. Vision matches your sentence to a template or to a fix in its solution library. It always lands as a draft you can check and change.
2. Select a step to change it in the panel on the right. Use the + buttons between steps to add one. Use the arrow keys to move between steps and Delete to remove one where allowed.
3. Problems are shown on the step and next to the field, in plain words. Fix them before you publish.
4. Choose Dry run. The trigger and conditions run against your current data and each app plans each change. Nothing is submitted, sent or changed. You see exactly what would happen, step by step.

Publish

Choose Publish for approval. A different organization administrator has to approve it, and the same goes for every new version and every roll back. Until then it is a draft, and drafts never run. Once live, the workflow runs with the permissions of the person who published that version, checked again at every step. If they lose access to an action, that step fails and the run stops. When a new version goes live, runs of the old version that are still waiting or running are stopped, and the new publisher becomes the owner of the new version only. A change a stopped run had already sent to an app stays open there, because a workflow can’t withdraw it: the approving administrator sees it before and after approving, and the run page flags it. Reject it in the app. The list of people who may start the workflow is shown as part of what the administrator approves.

Who can start it

The owner can always start a manual workflow. Under Who can start it you can add other people (up to 10); the list is part of the version, so another administrator approves it with the rest. Administrators who are not the owner or on the list can edit a workflow but can’t run it. A person who starts a run needs the action in their own app list, can’t approve the workflow’s extra sign-off, and can’t approve the change in the app either: the app treats them as one of the people who asked for it.

Follow the runs

Run history shows every run as a timeline: planned, waiting for approval, approved by (names), running, verified or failed, with a link to the job in the app and its evidence. Each change shows its Target, the exact setting the finding or your answer turned into, before the app’s people are asked. Filter by workflow, status and date. Finished runs are kept for 180 days.

If the app doesn’t answer clearly when a change is sent, the step stops with a note to check the app’s approvals before you start it again. It is never sent twice automatically.

Stay in control

• Pause workflow stops one workflow from starting or sending anything. An administrator’s Pause all Vision jobs switch (under Jobs) stops every workflow’s submissions too; runs wait and carry on when it is turned off.
• Versions keep every change with a readable list of what changed. Roll back makes the older version a new draft, which needs the same approval to go live.
• Everything is in your organization’s audit trail: created, edited, publish requested and approved, each run and each step.

For administrators

• Approve or reject publish requests from Automation. You can’t approve one you asked for or ever edited.
• Add a Microsoft Teams or Slack incoming webhook under Notification channels. It is stored encrypted and never shown again. Chat messages are sent as plain text, so a finding can’t add links, formatting or @mentions. E-mail from a workflow goes only to the owner, to people in your organization, or to addresses at a domain your organization has verified.

Options you can turn on

These options are off or minimal until you set them. Each one has a What does this do? link beside it in the product that explains the same things in brief.

Notification channels for workflows

E-mail always works. To let workflows post to Microsoft Teams or Slack, open Automation, then Notification channels, and paste an incoming webhook address for each. The address is stored encrypted and only its host is shown again. Use Remove to stop workflows posting to a channel.