---
title: Automations
description: Turn findings into fixes at tenant scale - suggested remediations counted against your real data, a grace period and a human review queue before anything is touched, executed natively through Microsoft.
icon: Zap
---

# Automations

Every other screen in 1Security answers _"what is wrong?"_. This one answers the question that follows it: **"We found four thousand problems - now what?"** Automations turn a finding into a fix that runs by itself, at tenant scale, with a review window in front of it so nothing is ever remediated behind your back.

## What You Can Achieve

<Cards>
  <Card
    title="Fix at tenant scale, not one file at a time"
    description="An 'anyone with the link' cleanup across 12,000 files, or Copilot indexing switched off on every externally exposed sensitive site, is one automation - not a month of manual admin work or a PowerShell script nobody wants to own."
  />
  <Card
    title="See exactly what it would do - before you enable it"
    description="Every suggested automation carries a live count of the resources it currently matches, and one click opens the actual list. You enable a fix knowing the blast radius, not guessing it."
  />
  <Card
    title="Keep a human in the loop"
    description="Give an automation a grace period and it stages proposals instead of firing. Approve, reject, or let the clock run out and let it proceed - your call, per resource or in bulk."
  />
  <Card
    title="Prove the remediation happened"
    description="Runs, actions fired, resources remediated and a per-resource ledger of every change - so 'we fixed it' is a record you can hand to an auditor, not a claim."
  />
</Cards>

## Suggested Automations, Already Counted Against Your Tenant

The screen opens on a board of **suggested automations** - a curated catalog of 26 remediation policies in 13 groups, each keyed by the action it performs and sorted into four themes:

- **AI safety** - stop Copilot from indexing sites that hold sensitive data and are reachable externally.
- **Oversharing** - remove risky link scopes, make sensitive sites private, restrict external sharing, expire external access.
- **Hygiene** - disable inactive accounts and accounts without MFA, assign owners to ownerless sites, delete orphaned sites and groups, purge ancient files, disable stale Windows devices.
- **Cost** - reclaim licenses from dormant users, disable apps nobody has used.

Each card shows **how many resources in your tenant match right now**. That number is not a marketing estimate: the suggestion is evaluated by the same policy engine that powers [trends](/en/docs/screens/trends), against your live permission graph, and refreshed continuously. On a tenant that has never enabled anything, the board still tells you how big each problem is.

<Callout type="info">
  Suggestions are counted, never executed. Until you explicitly enable one, a
  suggestion is a read-only measurement - it raises no alert, sends no mail and
  performs no action. Enabling is a deliberate act: you pick which policies in
  the group to switch on, and confirm.
</Callout>

**Evaluate** opens the group and lists the actual resources behind each number, with a switcher between the policies in the group, the conditions each one uses, and the arguments the action would run with. Suggestions whose defaults are illustrative - an allowed-domains list, an owner to assign - are flagged **Review before enabling** and left unchecked, so nothing ships with example data in it. **Review & customize** opens the policy in the editor, where you change conditions, arguments, name and severity before it ever runs; the edit is kept for your tenant and survives future catalog updates.

## What an Automation Actually Is

An automation is a **policy plus an action**. The policy half is exactly the mechanism behind trends: conditions over the permission graph - _sites containing sensitive information AND shared with anyone_, _users with no sign-in for 90 days_, _files with organization-wide links AND sensitive content_. The action half is what to do about the resources that match.

Because it is the same engine, automations inherit the real-time evaluation path: when audit-log activity changes a resource, the affected policies are re-evaluated within minutes, and only the changed slice is re-verdicted. Newly matching resources become new proposals; resources that stop matching quietly drop out.

### The Action Catalog

Actions execute against Microsoft 365 through Graph and the SharePoint admin APIs, and cover every resource type in the product:

- **Sites** - sharing capability, default link permission and type, anonymous-link expiry, allowed/blocked sharing domains, external-user expiration, site privacy, block or allow Copilot org-wide search, add/remove owners and members, delete site.
- **Files** - remove links by scope, remove a user from a link, revoke or downgrade a user's permission, revoke all of a user's access (direct, link, group and site-derived), delete files and lists.
- **Users** - disable or enable the account, add/remove licenses (or strip all of them), add/remove group membership, add/remove site ownership or membership, delete user.
- **Groups** - add/remove members and owners, delete group.
- **Apps** - disable or enable a service principal.
- **Devices** - disable or enable a registered device.
- **Email** - delete, move to junk or deleted items, mark read/unread.
- **Licenses** - assign to or remove from users.

The same catalog powers **manual actions**: select rows on any list or open a resource drawer and run the action once, by hand, against exactly the resources you picked. Manual runs and policy runs land in the same ledger, so the record of "who changed what" is one story.

<Callout type="info">
  Composite actions understand the permission graph. *Revoke a user's access to
  these files* resolves every path that access arrives through - direct grants,
  sharing links, group membership, site membership - removes what can be removed
  automatically, and asks for confirmation on the paths whose removal would
  affect other people, with the blast radius shown per source.
</Callout>

## The Grace Period: Nothing Fires by Surprise

An automation with a **review window** does not act when it matches. It stages a **proposal** for each resource and starts a countdown - the default when you enable a suggestion is **72 hours** (instant, 24 hours and 7 days are the other presets).

While the clock runs, the proposal sits in the **review queue**:

- **Approve** - execute now, without waiting out the window.
- **Reject** - never do this to this resource, and **snooze** it (30 days by default) so the policy cannot re-propose the same fix tomorrow.
- **Withdraw** - drop it from this run only. The policy will propose it again within minutes; use it to clear the queue, not to say no.
- **Do nothing** - when the window elapses, the action proceeds. That is the point of a grace period: the default is progress, and your attention is only required for the exceptions.

Set the policy to **manual approval** instead and the window never auto-releases - nothing executes until a human approves it.

Review works in bulk. Select a filtered slice of the queue and approve or reject it in one go; the decision is applied by **match**, not by a frozen list of ids, so proposals that arrive while you are reading are included rather than silently skipped. Rejected resources live on in **snoozed items**, where you can release them early.

Every proposal carries the resource it targets - clickable through to that file, site, user, agent or device in a new tab - the policy that proposed it, the action and its arguments, and a live countdown to execution.

## Watching the Engine Work

- **Four counters** at the top: active automations, runs in the last 30 days, resources remediated in the last 30 days, and open matches waiting.
- **A liveness strip** - _"Automation engine live - last evaluation 3 minutes ago"_. Cameras-on evidence that the thing is running, not a dashboard that looks the same whether or not the engine died last Tuesday.
- **Actions performed** - a multi-line chart of executed actions over 1 hour, 1 day, 7 days, 30 days or 1 year, split per action type, with click-through from any point to the exact resources changed in that bucket.
- **Per-automation activity** - each active card reports _"N actions fired across M runs, last X ago"_, or says plainly that it has not fired yet.
- **Pause and resume** - any automation can be paused from its card and resumed later. A paused automation keeps its configuration and its counts; it simply stops acting.

Automations also participate in [unified alerting](/en/docs/screens/trends): give one an instant trigger and you are mailed when its match count spikes against its own baseline, or when it crosses a threshold you set - independent of whether the automation itself is allowed to act.

## Working With Microsoft, Not Against It

Every action is a native Microsoft operation. 1Security holds no shadow permission model and no parallel state: disabling an account is `accountEnabled = false` in Entra, removing a link is a SharePoint link removal, blocking Copilot indexing is the site's own restricted-search setting. Whatever you do here is visible and reversible in the Microsoft admin centres, and anything an admin changes there is picked up by the next evaluation.

- **Write access is separate and opt-in.** 1Security's read-only application cannot change anything. Remediation requires a second, explicitly consented write application - until it is connected, the automations screen counts and previews but the actions stay unavailable.
- **Detection needs no premium licensing.** Suggestion counts, previews and the permission graph behind them work on Business Basic. Actions need the write consent, and a few specific ones carry Microsoft's own constraints: disabling apps needs `Application.ReadWrite.All`, and device enable/disable needs `Device.ReadWrite.All` plus the Cloud Device Administrator role, and Microsoft only permits it on Windows devices - so the seeded device automation is scoped accordingly.
- **Discovery-only resources are excluded automatically.** Shadow devices have no Entra object to disable, so they are filtered out at match time rather than failing at execution.

## Rollout Patterns

<Callout type="info">
  **The safe first automation**: pick the suggestion with the largest count that
  you already agree with - usually *remove organization-wide links from
  sensitive files* - and enable it with a **72-hour window** and **manual
  approval**. For a week, review the queue rather than the tenant. Once the
  proposals stop surprising you, switch approval to automatic and keep the
  window. You end up with a remediation loop that runs itself and still lets you
  veto anything.
</Callout>

- **Copilot readiness** - block Copilot indexing on externally exposed sensitive sites and on orphaned or inactive sites before a Copilot rollout, so the AI's context window is not built from the worst-governed corners of the tenant.
- **Offboarding that finishes itself** - disable inactive accounts, reclaim their licenses, and revoke their file access, all keyed on last activity rather than on someone remembering to file a ticket.
- **Continuous external-sharing hygiene** - expire external access and restrict sharing capability on sites that keep drifting open; the automation re-applies the setting every time a site drifts back.
- **Quarterly cleanup with evidence** - orphaned sites and groups, ancient files and stale devices, each with a review window, so the quarter's cleanup is one approved queue and a ledger of exactly what was removed.
