--- title: Actions description: Every change 1Security can make in your Microsoft 365 tenant - what each action does, whether you can take it back, and whether we actually check that it landed. icon: ListChecks --- # Actions Every change 1Security makes in your tenant ends up in one place: the **Action Center**. It doesn't matter whether an [automation](/en/docs/screens/automations) proposed the change, a security case staged it after a one-time scan, you clicked it yourself on a file, a site or a user, or you fired one of the suggested response actions on an [anomaly](/en/docs/screens/anomalies) - block sign-in, revoke consent, quarantine an agent - or on a [location](/en/docs/screens/locations) (the Review tab and the location drawer offer **Disable Account** and **Remove All Licenses** for the people who got in from a place the list does not permit) - it lands in the same ledger, with the same status and the same paper trail. This page is the catalog behind that ledger. For every action we can run, it tells you what it changes, whether you can take it back, and whether we actually check that Microsoft did what we asked. ## Before you read the tables Three of the columns describe promises rather than features, so they deserve a word of explanation. ### Confirmation - do we check, or do we trust? An action can reach Microsoft in two ways, and the honest answer is that not every action gets the careful one yet. - **Confirmed** is the careful one. We send the write, wait, then read the resource back from Microsoft and compare. Only when the read agrees do we call it _Applied_; until then the row says _Confirming_. If Microsoft accepted the write but the resource never comes back the way we asked, we say _Unconfirmed_. That's us admitting we don't know, rather than guessing in your favour. Every action fired by an automation runs this way, and so does every revert. - **Immediate** is the quick one. When you fire the action by hand it runs inside your request, and the row says _Applied_ or _Failed_ based on Microsoft's reply alone - no second look. It's fast, and for most settings it's fine, but "Microsoft said OK" and "it's really there" are not always the same sentence. The column tells you which path a **manual** run takes. The same action fired by an automation is always confirmed. We're moving actions from _Immediate_ to _Confirmed_ one family at a time, so expect this column to keep changing in that direction. ### Revert - can we take it back? The **Revert** button on a row is only offered when we can honestly do something with it. The column says which of four situations you're in: - **Yes** - we undo it ourselves, either by running the opposite action or by writing back the value we noted down before the change. - **Yes, for 30 days** - Microsoft holds deleted users for 30 days. While that window is open we can restore them, and the row shows how long you have left. - **Manually** - we can't drive the undo, but you can, and the row tells you where: the recycle bin, Recoverable Items in Outlook, dragging a message back to its folder, or setting a value back by hand. - **No** - there's no way back, or none we've verified. We'd rather tell you that up front than let you find out from a greyed-out button. ### Availability - live, or on its way? - 🟢 **Live** actions run on real tenants today. - ⏳ **Coming soon** actions are already in the picker, with a badge, and the server refuses to run them. Nothing in that state is known to be broken. An action goes live the moment we've run it end to end on a real tenant, write and read-back both, and not a day earlier. That's the bar, and it's why some actions that look trivial are still waiting. ### License - does your tenant have what it needs? Almost every action runs on the subscription you already have. Two do not: **Block Content from Copilot** and **Allow Content for Copilot** depend on Microsoft's Restricted Content Discovery, which needs a premium SKU on your side. Wherever you can pick or run an action - the policy builder, the resource lists, the drawers - a **Missing license** notice appears beside those two when your organization does not appear to hold what they need, and a policy whose automations include one carries the same marker in the list. The notice is advisory. It never blocks you: you can still pick the action, save the policy or run it by hand, and we will send it every time - Microsoft decides. When we cannot tell for sure (the licenses were last read a while ago, or the edition you hold has no published identifier) the notice softens to **License may be missing**. Open **Action readiness** from the Action Center or the Licenses screen to see which of the two parts is missing and what would unlock it, and read [Requirements](/en/docs/requirements) for the exact SKUs and a checker that reads your Your products export before you connect. On the demo tenant every action is a simulation. It walks through _Running_, _Confirming_ and _Applied_ so you can see how the ledger behaves, but nothing is sent to Microsoft. ## What the statuses mean | Status | What it's telling you | | :------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Awaiting review** | An automation proposed this and gave you a review window. If nobody rejects it, it goes ahead when the window closes. | | **Approved**, **Queued**, **Running** | On its way to Microsoft. Usually a matter of seconds. | | **Confirming** | Microsoft accepted the write. We're now reading the resource back to prove it actually changed. | | **Applied** | The change is in your tenant. For a confirmed action we read it back ourselves; for an immediate one, this is what Microsoft's reply said. | | **Unconfirmed** | Microsoft accepted the write, but we couldn't prove the effect. Open the row and hit _Check now_, or look at the resource yourself. | | **Failed** | Microsoft refused the write, or a later read found a different value from the one we wrote. Either way, your tenant is not in the state you asked for. | | **No change needed** | We looked before writing and the resource was already where you wanted it, so we left it alone. | | **Rejected**, **Withdrawn** | Stopped before it ran - by a reviewer, or by the person who asked for it. | ## The catalog Grouped by the kind of resource you run the action on. The bold name is what you'll see in the picker; the code next to it is the id you'll find in the evidence export and in conversations with our support. ### Sites | Action | What it does | Revert | Confirmation | Availability | | :--------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------- | :------------------------------------- | :----------- | :------------- | | **Set Sharing Capability** `Site_SetSharingCapability` | Decides who the site can be shared with at all. | Yes | Immediate | 🟢 Live | | **Set Default Link Permission** `Site_SetDefaultLinkPermission` | Whether a freshly created sharing link grants view or edit. | Yes | Immediate | 🟢 Live | | **Set Default Sharing Link Type** `Site_SetDefaultSharingLinkType` | Whether a freshly created sharing link is direct, internal or anonymous. | Yes | Immediate | 🟢 Live | | **Set Anonymous Link Expiration (Days)** `Site_SetAnonymousLinkExpirationDays` | How many days an anonymous link lives. Overrides the tenant policy for this site. | Yes | Immediate | 🟢 Live | | **Control Override of Anonymous Link Policy** `Site_ControlOverrideAnonymousLinkPolicy` | Whether the site follows its own anonymous-link expiration or the tenant default. | Yes | Immediate | 🟢 Live | | **Set External User Expiration (Days)** `Site_SetExternalUserExpirationDays` | How many days an external user keeps access. Overrides the tenant policy for this site. | Yes | Immediate | 🟢 Live | | **Control Override of External User Expiration Policy** `Site_ControlOverrideExternalUserExpirationPolicy` | Whether the site follows its own external-user expiration or the tenant default. | Yes | Immediate | 🟢 Live | | **Set Allowed Sharing Domains** `Site_SetAllowedSharingDomains` | Replaces the list of outside domains the site may be shared with. | Yes | Immediate | 🟢 Live | | **Set Blocked Sharing Domains** `Site_SetBlockedSharingDomains` | Replaces the list of outside domains the site may never be shared with. | Yes | Immediate | 🟢 Live | | **Clear All Domain Sharing Restrictions** `Site_ClearDomainSharingRestrictions` | Wipes both domain lists. | Yes | Immediate | 🟢 Live | | **Block Content from Copilot** `Site_BlockCopilotOrgWideSearch` | Keeps the site's content out of Copilot's organization-wide search. | Yes | Immediate | 🟢 Live | | **Allow Content for Copilot** `Site_AllowCopilotOrgWideSearch` | Lets Copilot search the site's content again, unless tenant settings say otherwise. | Yes | Immediate | 🟢 Live | | **Control Site Privacy** `Site_ControlSitePrivacy` | Flips the site between Private and Public, through its Microsoft 365 group. | Yes | Confirmed | 🟢 Live | | **Add owners** `Site_AddOwner` | Puts the chosen people in the site's owner group. | Yes | Confirmed | 🟢 Live | | **Remove owners** `Site_RemoveOwner` | Takes the chosen people out of the site's owner group. | Yes | Confirmed | 🟢 Live | | **Add members** `Site_AddMember` | Puts the chosen people in the site's member group. | Yes | Confirmed | 🟢 Live | | **Remove members** `Site_RemoveMember` | Takes the chosen people out of the site's member group. | Yes | Confirmed | 🟢 Live | | **Delete Site** `Site_DeleteSite` | Deletes the site together with the groups directly connected to it. | Manually (site collection recycle bin) | Confirmed | ⏳ Coming soon | Most site actions are settings, and a setting has no opposite - there's no "un-set sharing capability". We revert them by remembering the value the site had before and writing it back, which is why every one of them says _Yes_. The two Copilot actions are the only ones in this catalog that need a premium Microsoft SKU. If they show a _Missing license_ notice, [Requirements](/en/docs/requirements) says what to buy or assign. _Delete Site_ is the one we're holding, and it's worth explaining why. A site connected to a Microsoft 365 group can't be fully deleted with the application identity 1Security uses. The only route that works deletes the group permanently first, and that throws away its 30-day restore along with its mailbox, Teams and Planner. Whether an action should do that on your behalf is a decision we haven't made yet, so until we have, the button stays badged. ### Users | Action | What it does | Revert | Confirmation | Availability | | :------------------------------------------------------------- | :-------------------------------------------------------------------- | :----------------------------------- | :----------- | :----------- | | **Disable Account** `User_DisableAccount` | Locks the account out. No more sign-ins. | Yes | Confirmed | 🟢 Live | | **Enable Account** `User_EnableAccount` | Lets a disabled account sign in again. | Yes | Confirmed | 🟢 Live | | **Delete User** `User_DeleteUser` | Removes the user from the tenant. | Yes, for 30 days | Confirmed | 🟢 Live | | **Add License** `User_AddLicense` | Gives the user the chosen licenses. | Yes | Confirmed | 🟢 Live | | **Remove License** `User_RemoveLicense` | Takes the chosen licenses away from the user. | Yes | Confirmed | 🟢 Live | | **Remove All Licenses** `User_RemoveAllLicenses` | Takes every license away from the user. | Yes (we put back the set we removed) | Confirmed | 🟢 Live | | **Add to groups** `User_AddToGroups` | Makes the user a member of the chosen groups. | Yes | Confirmed | 🟢 Live | | **Remove from groups** `User_RemoveFromGroups` | Removes the user from the chosen groups, as a member and as an owner. | Yes (as a member) | Confirmed | 🟢 Live | | **Add to sites as owner** `User_AddToSitesAsOwner` | Puts the user in the owner group of the chosen sites. | Yes | Confirmed | 🟢 Live | | **Remove from sites as owner** `User_RemoveFromSitesAsOwner` | Takes the user out of the owner group of the chosen sites. | Yes | Confirmed | 🟢 Live | | **Add to sites as member** `User_AddToSitesAsMember` | Puts the user in the member group of the chosen sites. | Yes | Confirmed | 🟢 Live | | **Remove from sites as member** `User_RemoveFromSitesAsMember` | Takes the user out of the member group of the chosen sites. | Yes | Confirmed | 🟢 Live | Every user action has had its end-to-end run on a real tenant and is live. Under the hood, the license and membership actions are the same writes as the license, group and site actions further down - just started from the user's side. One thing to know about _Remove from groups_: it takes the user out as an owner too, but undoing it puts them back as a member only. And on a site connected to a Microsoft 365 group, the site actions write to that group's owners or members, which is where SharePoint takes the site's owners and members from. ### Files | Action | What it does | Revert | Confirmation | Availability | | :----------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------- | :----------- | :----------- | | **Delete files** `File_DeleteFiles` | Deletes the matched files. On Microsoft's side they go to the recycle bin. | Manually (recycle bin) | Confirmed | 🟢 Live | | **Remove links by scope** `File_RemoveLinksByScope` | Removes every sharing link of the chosen scopes from the file. | No (a new link gets a new URL) | Immediate | 🟢 Live | | **Revoke user access** `File_RevokeUserAccess` | Cuts a person off from a file through every route that lets them in: a direct permission, a sharing link, a group or a site membership. | No | Immediate | 🟢 Live | | **Revoke user permission** `File_RevokeUserPermission` | Removes one person's direct permission on the file. | No | Immediate | 🟢 Live | | **Downgrade user permission** `File_DowngradeUserPermission` | Turns one person's direct permission on the file into read-only. | Manually (set it back in SharePoint) | Immediate | 🟢 Live | | **Remove user from link** `File_RemoveUserFromLink` | Takes one person off the file's sharing links. | No | Immediate | 🟢 Live | _Revoke user access_ is the big one. It chases a person's access to a file through every route that grants it and closes all of them at once. That's also why it can't be reverted: putting the access back would mean rebuilding whichever of those routes granted it, and we haven't verified we can do that faithfully. It lives on the Files list; the last three live in the **Manage access** dialog inside a file's drawer. None of the four is offered in the automation builder. _Remove links by scope_ has a hard _No_. Once a sharing link is gone, Microsoft mints a new id and a new URL for any replacement, so the old link is dead for everyone who had it. Not "we can't bring it back" - nobody can. ### Apps | Action | What it does | Revert | Confirmation | Availability | | :---------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | :----- | :----------- | :------------- | | **Disable app** `App_DisableApp` | Switches the enterprise app (its service principal) off. Nobody can sign in to it and it stops receiving tokens. | Yes | Confirmed | 🟢 Live | | **Enable app** `App_EnableApp` | Switches a disabled enterprise app back on. | Yes | Confirmed | 🟢 Live | | **Restrict to assigned users** `App_RestrictToAssignedUsers` | Only people and groups explicitly assigned to the app can sign in. Everyone else loses access, and future consent needs an administrator. | Yes | Confirmed | 🟢 Live | | **Allow all users** `App_AllowAllUsers` | Opens the app back up to everyone in the tenant, under the tenant's consent policy. | Yes | Confirmed | 🟢 Live | | **Revoke delegated consent** `App_RevokeOAuthGrants` | Deletes every delegated permission grant the app holds - per-user consent and tenant-wide admin consent alike. Tokens already issued last until they expire. | Yes | Confirmed | ⏳ Coming soon | | **Remove application permissions** `App_RemoveAppRoleAssignments` | Removes every application permission (app role assignment) the app holds, so it can no longer act as itself against tenant data. | Yes | Confirmed | ⏳ Coming soon | The people cut off by _Restrict to assigned users_ don't get a row of their own - nothing on their accounts changes, Entra just stops honouring a sign-in they never had an assignment for. Their number is in the warning you see before you confirm, and in the evidence afterwards. ### Licenses | Action | What it does | Revert | Confirmation | Availability | | :---------------------------------------------- | :--------------------------------------------- | :----- | :----------- | :----------- | | **Assign to users** `License_AssignToUsers` | Gives the license to the chosen people. | Yes | Confirmed | 🟢 Live | | **Remove from users** `License_RemoveFromUsers` | Takes the license away from the chosen people. | Yes | Confirmed | 🟢 Live | One thing Microsoft will refuse and we don't yet catch for you: assigning a license to a user with no usage location, or from a SKU with no free seats. If an assignment doesn't go through, that's the first thing to check. Set the usage location on the user, or free a seat, and run it again. ### Devices | Action | What it does | Revert | Confirmation | Availability | | :---------------------------------------- | :-------------------------------------------------------------- | :----- | :----------- | :----------- | | **Disable device** `Device_DisableDevice` | Disables the device in Entra ID, so nobody can sign in from it. | Yes | Confirmed | 🟢 Live | | **Enable device** `Device_EnableDevice` | Lets a disabled device sign in again. | Yes | Confirmed | 🟢 Live | Microsoft only lets an app change this on Windows devices, and only once the write app holds the Cloud Device Administrator role; any other device is reported as not applied. A device we only know from sign-in logs has no object in Entra, so it is skipped and reported as not applied too. For every other device we read the setting back from Entra before we call it applied. ### Agents | Action | What it does | Revert | Confirmation | Availability | | :------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------- | :----------- | :------------- | | **Quarantine** `Agent_Quarantine` | Stops the agent answering on its published channels. Its makers can still open and test it. Copilot Studio and Microsoft Copilot agents; needs Power Platform actions connected in Integrations. | Yes | Confirmed | 🟢 Live | | **Reassign owner** `Agent_ReassignOwner` | Makes the chosen person the agent's owner. For a Copilot Studio agent that is its Copilot Studio owner; for any other agent with an identity of its own, its identity's Entra owners. Sponsors are not changed. A Copilot Studio agent needs Power Platform actions connected in Integrations. | Yes (we put back the owner Microsoft reported just before the change) | Confirmed | ⏳ Coming soon | | **Disable identity** `Agent_DisableIdentity` | Switches the agent's Entra identity (its service principal) off. Microsoft then blocks access and token issuance for it; tokens already issued last until they expire. Only for agents with an identity of their own. | Yes | Confirmed | 🟢 Live | | **Enable identity** `Agent_EnableIdentity` | Switches a disabled agent identity back on. An identity Microsoft itself disabled cannot be re-enabled here. | Yes | Confirmed | 🟢 Live | Quarantine, its Release and Copilot Studio ownership live on the Power Platform, which only talks to a signed-in administrator, so they need Power Platform actions connected in Integrations (the Copilot Studio actions module, under Remediation). The Agents screen does not offer that connection. Microsoft records those changes as made by the administrator who connected it, not by 1Security. Disable identity and Enable identity need the write app re-consented for the agent identity permissions; the picker says so beside them until that is done. We read every one of these back from Microsoft before we call it applied. How quickly a quarantined agent stops answering on its channels is not something we have measured yet. Reassign owner stays held until it has run and been reverted on a real agent; on the demo tenant you can already see what it will look like. Putting a Copilot Studio owner back goes through the same route, so that revert also needs Power Platform actions connected in Integrations. And where our reading just before the change found no owner at all, there is nothing to put back: a Copilot Studio agent always has exactly one owner, so choosing who holds it is an administrator's call in Copilot Studio, not a button here. When you open **Add action** for a single agent, a **Smart actions** switch sits at the top, on by default and remembered in your browser. While it is on, the list shows **Smart action: Restrict agent** in place of Quarantine, Disable identity and Enable identity. It shows the two stops as what they prevent rather than by name: **stop it using its own permissions** (Disable identity: people still chat with it, but anything it reads, sends or looks up with its own account fails), **hide it and block its answers** (Quarantine: it leaves everyone's agent list and replies with an error, while its makers can still open and test it), or **both**. The card says which action Run sends before you confirm; Both sends two, one after the other, each with its own row in the ledger. A stop that is already on shows as _Applied_, and Run then undoes it with the matching Release or Enable identity. Switch Smart actions off to pick the plain actions by name. The smart action is only in this picker: automations and presets keep naming the actions themselves. ### Emails | Action | What it does | Revert | Confirmation | Availability | | :--------------------------------------------------- | :---------------------------------------------------------------------------------------- | :------------------------------- | :----------- | :----------- | | **Delete** `Email_Delete` | Deletes the selected messages from the affected mailboxes. Microsoft skips Deleted Items. | No | Confirmed | 🟢 Live | | **Move to deleted items** `Email_MoveToDeletedItems` | Moves the selected messages to Deleted Items. | Manually (move the message back) | Confirmed | 🟢 Live | | **Move to junk** `Email_MoveToJunk` | Moves the selected messages to Junk Email. | Manually (move the message back) | Confirmed | 🟢 Live | | **Mark as read** `Email_MarkAsRead` | Marks the selected messages as read. | Yes | Confirmed | 🟢 Live | | **Mark as unread** `Email_MarkAsUnread` | Marks the selected messages as unread. | Yes | Confirmed | 🟢 Live | One thing worth knowing about the two moves: Microsoft only lets us move a message _into_ Junk or Deleted Items, never back to the folder it came from. So reverting one of those is a drag-and-drop for the mailbox owner, not a button for us. _Delete_ cannot be reverted. Microsoft does not put the message in Deleted Items - it leaves the mailbox straight away, so there is nothing in the folders for the owner to drag back and no button for us. If you only want it out of sight, use _Move to deleted items_.