SharePoint

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). Copy an existing content type onto a site or list — how a library is made to accept a document type it did not previously accept, and the normal alternative to creating one from scratch, since most of the time the type already exists somewhere and only needs applying. Check first which content types the list will accept: SharePoint will not put a document content type on a plain list and the refusal does not explain itself.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). Pull a published content type down from the content type hub — and this is also the SYNC operation: running it again on a type already present updates the local copy to match the hub. That is how an organisation-wide records schema reaches a site created after the schema was. ASYNCHRONOUS: Microsoft accepts and performs it in the background, so this reports accepted rather than done, and the site operations read shows whether it finished.

DESTRUCTIVE — THE WHOLE SITE BECOMES READ-ONLY FOR EVERYBODY. This is not a delete and nothing is lost, but it is the widest single switch available without a new admin grant: an archived site stops accepting writes from every user, every workflow and every integration at once, and people who were mid-task find out by being refused. IT IS REVERSIBLE, which is why it ships — sharepoint_unarchive_site is in this same migration — but reactivation is not instant, so the site stays read-only for a while after the call succeeds. BETA.

DESTRUCTIVE BY REACH, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). Associating means the content type is APPLIED TO THE LISTS IN EVERY SITE ATTACHED TO THOSE HUBS, which for a large hub is an unbounded number of libraries belonging to teams who were not asked. Propagating to existing lists extends that to lists that already exist, not only new ones.

Release a checked-out document — the inverse of checking one out, and it ships in the same migration for a concrete reason: a check-out with no check-in is a document nobody else can edit until an administrator intervenes. Checking in as a published version rather than a draft is off by default, because on a library with an approval flow that is the difference between saved and visible to everyone.

Check a document out so nobody else edits it while an agent works on it. Nothing is lost and checking in reverses it, so it is not marked destructive — but READ THIS BEFORE GRANTING IT: a checkout the agent never releases BLOCKS EVERY OTHER USER from editing that document until a site administrator discards it. The safe shape is check out, upload, check in, and an agent that cannot finish should check in anyway rather than leave the lock.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). Copy a file into a content type default content location, so that every document set created from that type afterwards starts with a copy of it — how an organisation puts a standard cover sheet or checklist into every new matter folder. Additive. The source file is identified by its listItemUniqueId, which sharepoint_get_file_list_item and sharepoint_get_list_item_sharepoint_ids produce.

Copy a document or folder within a library. ADDITIVE: the source is untouched and the conflict behaviour is pinned so a copy can never overwrite something already at the destination — which is why this is not destructive while moving is. Microsoft performs the copy ASYNCHRONOUSLY and answers accepted before it has happened, so this waits for the real outcome and reports still running honestly rather than calling an unfinished copy a success. Microsoft does not copy item permissions with the content: treat the copy as new content, not as a clone.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). Add a column at site, list or content-type scope. Additive on its own — it adds an empty field to every existing item rather than changing one — WITH ONE EXCEPTION WORTH PAUSING ON: marking it required makes every future write to that list fail unless it carries the new field, including writes from workflows and integrations that predate the column.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). Create a content type on a site or a list, derived from a parent such as Document, Item or Document Set. Additive, and its inverse ships in the same migration.

Capture a version of a document set — a snapshot of an entire folder of documents plus its metadata, which is how records-managed SharePoint records the state of this matter as at the closing date. Additive: it changes nothing that exists. The connector could already READ the history of these snapshots and could not take one.

Create a folder in a document library. Purely additive, and it closes a real gap: the upload action own contract says folders in the path must already exist, so the one action that could put a document in the right place could not create that place. Conflict behaviour defaults to FAIL so an existing folder is never silently replaced by a call that meant to create one.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All) — Microsoft offers no lower tier and Sites.ReadWrite.All does not reach it. Create a new list or document library on a site. Additive, and it touches nothing that exists. IT HAS NO INVERSE: Microsoft Graph publishes no delete and no rename for a list, in version 1.0 or beta, so a list created by mistake has to be removed by a person in SharePoint. The template decides which columns the list is born with and cannot be changed afterwards.

Create one new item (row) in a SharePoint list from a set of column values. Additive — every existing item is left untouched, which is why this is not marked destructive. Column values must use internal names from the read-columns action.

Create a site page. It is created as a DRAFT and is not visible to anybody until it is published, so this touches nothing that exists and is not marked destructive. Its inverse — deleting a page — ships in the same migration.

Add a horizontal section — a row — to a site page layout. Additive, and it lands in the page DRAFT, invisible to readers until the page is published. Together with the web part actions this is what makes editing a page surgical: updating a page canvas layout is a FULL REPLACE and silently deletes every section not included, and these actions avoid that entirely.

Add the vertical section — the sidebar rail — to a site page. Additive. There is at most one per page and asking for a second is refused by Microsoft Graph.

Add ONE web part to a site page without rewriting the layout. THIS IS THE ACTION THAT MAKES UPDATING A WHOLE PAGE A LAST RESORT: the page update replaces the canvas layout wholesale, so anything not included is deleted with no warning, while this adds one thing and leaves everything else alone. The change lands in the DRAFT. Microsoft rejects a web part type it does not recognise, and the error does not list the ones it does, so copy the shape from an existing part.

DESTRUCTIVE — create a sign-in-required sharing link for a document or folder, granting durable access to people who did not have it. THE SCOPE ARGUMENT IS REQUIRED AND HAS NO DEFAULT, which is the important part: Microsoft own default is the organisation default link type, and in a permissively configured tenant that is an ANONYMOUS link — a URL that serves the document to anyone holding it with no sign-in and, per Microsoft own documentation, with no expiry unless a tenant policy adds one. Anonymous is refused outright here. Only organization and users are accepted, both of which require the recipient to sign in, so the access is attributable, visible to sharepoint_list_file_permissions and revocable with sharepoint_delete_file_permission. Note the item may be a FOLDER, in which case the link reaches everything beneath it including documents added later. PASSING retain_inherited_permissions=false ALSO REQUIRES confirm_permission_reset='remove-all-existing-permissions' — it wipes every permission the item already carries and is a separate decision from confirm.

DESTRUCTIVE BY INTENT, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.Create.All). Provision a new SharePoint site. A site is not a record: it is a container with a URL, a membership model, a storage quota and an entry in the tenant site inventory. MICROSOFT GRAPH PUBLISHES NO DELETE AND NO RENAME FOR A SITE, in version 1.0 or beta — checked against Microsoft own methods table rather than assumed — so removing one afterwards is a SharePoint administrator task outside this API entirely. Site creation is also GOVERNED by tenant policy, which sharepoint_get_tenant_settings reads if that grant is enabled. BETA.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). Create a term at the top of a set or under another term. Additive: it widens what a managed-metadata column will accept, tenant-wide, which is worth knowing but is not a loss. Its inverse ships alongside.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). Create a term group — the top level of a taxonomy. Additive, and its inverse ships in this same migration.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). Pin or reuse a term into another term set. Additive — it adds a relation and moves nothing. MICROSOFT GRAPH PUBLISHES NO DELETE FOR A RELATION, in version 1.0 or beta, so this is one of the few writes here whose inverse does not exist at all.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). Create a term set inside a group — the vocabulary a managed-metadata column will draw from. Additive, and its inverse ships alongside.

DESTRUCTIVE, NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All), AND IT HAS NO INVERSE ANYWHERE. Deleting a list column BLANKS THAT COLUMN ON EVERY ROW AT ONCE. Schema does not go to the recycle bin, so the recycle-bin read will not show it and no administrator and no Microsoft support case can put the values back; recreating a column of the same name gives you an empty column. This is one of three actions in this connector with no way back — the others are permanently deleting a file and deleting a term set. If your organisation does not want an agent able to do this, do not grant this one action.

DESTRUCTIVE, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). The inverse of creating one. SharePoint refuses to delete a content type still in use, which is a genuine safety net, but the refusal arrives as a Microsoft Graph error rather than a list of what is using it. The content type does not go to the recycle bin.

DESTRUCTIVE — delete a file or folder from a document library. Wider than it looks: deleting a folder deletes everything beneath it. The item goes to the site recycle bin, from which Microsoft Graph exposes no restore.

DESTRUCTIVE — remove one permission from a document. THE INVERSE OF SHARING, and the only action here that can take back an anonymous link somebody created in the SharePoint interface, which makes it a net risk reduction rather than an added risk. THE HAZARD PEOPLE FORGET: removing an INHERITED permission on a folder where inheritance was broken can lock an entire team out of its own library, and Microsoft Graph will not say in advance which case it is. Read the permissions first and look at whether they are inherited.

DESTRUCTIVE — delete one item from a SharePoint list. The item goes to the site recycle bin, where a site collection administrator can restore it for 93 days by default, but Microsoft Graph exposes no restore call: Agentic Fabriq cannot undo this and neither can the agent that did it. The retention window is a tenant setting and may be shorter.

DESTRUCTIVE — delete a site page. It goes to the site recycle bin, where a site collection administrator can restore it; Microsoft Graph exposes no restore, so Agentic Fabriq cannot. This is the inverse of both creating a page and publishing one, because Microsoft Graph has no unpublish.

DESTRUCTIVE — delete one horizontal section of a page, taking its columns and every web part in them. There is no recycle bin below page level, so nothing here or in SharePoint restores the content. If the page was already published the change is not visible to readers until it is published again.

DESTRUCTIVE — delete a page vertical section and every web part in it. Nothing goes to a recycle bin.

DESTRUCTIVE — delete ONE web part from a page. A text web part content is the page own words and nothing restores it: there is no recycle bin below page level. Read it first if the content might be wanted.

DESTRUCTIVE, TENANT-WIDE, NOT RESTORABLE, AND NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). Deleting a term blanks the managed-metadata value on every item across every site that used it, and it takes the term CHILDREN with it, so removing a mid-level term of a deep vocabulary removes the branch. There is no taxonomy recycle bin.

DESTRUCTIVE AND TENANT-WIDE, AND NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). TAXONOMY HAS NO RECYCLE BIN. A group holds term sets and those hold terms, so every managed-metadata column anywhere in the tenant that points at one of them loses its vocabulary. SharePoint generally refuses to delete a group that still contains sets, which is the safety net, but that refusal is a Microsoft Graph error rather than a warning with a list attached.

DESTRUCTIVE, TENANT-WIDE, NOT RESTORABLE, AND NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). Deleting a term set destroys the vocabulary that EVERY managed-metadata column pointing at it draws from — on every site, in every library, at once. There is no taxonomy recycle bin, so neither Agentic Fabriq nor an administrator can put it back. This is one of three actions in this connector with no way back, and it is the widest of the three.

Release a checked-out document AND THROW AWAY every change made since it was checked out. The third exit from a checkout and the one a failing agent needs: checking in COMMITS whatever was written and makes a version of it, and simply abandoning the checkout leaves the document locked so nobody else can edit it. WHAT THIS DISCARDS CANNOT BE RECOVERED — the draft never became a version, so neither the version history nor the recycle bin has it. The document reverts to its state at checkout. Answers 423 if somebody else holds the checkout, which a signed-in user cannot discard.

Read one document CONTENT out of a library, returned base64-encoded. THE LARGEST FUNCTIONAL HOLE THIS CONNECTOR HAD: it could upload a document into a library — an upsert, so it could REPLACE one — and could not read a document back. Pure read, no state change. Documents above 25 MB are refused rather than truncated, because the bytes land in an agent context window.

Read a document CONTENT addressed by the library-relative PATH a human would paste, in one call instead of resolving the path to an id and then downloading it. Same permission and same size ceiling as sharepoint_download_file. Refuses a folder path rather than returning an empty result. The bytes are base64-encoded into the tool result and land in an agent context window, so documents above the connector ceiling are refused rather than truncated.

Read the content of one PAST version of a document, base64-encoded. The read that makes restoring a version a decision rather than a gamble: the old content can be looked at before it is put back over the current one.

Follow a site so it appears in the signed-in user own SharePoint. It changes one person navigation and nothing else. BETA.

List the content types that MAY be added to one list. The precondition read for copying a content type onto a library: SharePoint will not accept a document content type on a plain list, and the refusal does not explain itself. Microsoft publishes this function precisely so a caller does not have to discover the rule by being refused.

Read ONE column definition at site, list or content-type scope, including the INTERNAL name a write must use and exactly one type facet. Which scope you ask matters: the same column can be required on a content type and optional on the site definition it came from, and that difference is what a caller is trying to establish before a write.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All) even though it is a read — Microsoft gates it at the same permission as the writes it precedes. It answers which published hub content types this site or list is actually allowed to take, rather than leaving a caller to try one and be refused.

Read one content type definition, at site scope or list scope.

Read the content type one content type was DERIVED FROM. Content types inherit, and the parent decides what a child may change — trying to remove an inherited column, or to edit a sealed ancestor, fails with a Microsoft Graph error that names none of that. This makes the failure predictable in advance.

Read the site DEFAULT document library — the one called Documents or Shared Documents, which holds the overwhelming majority of what anyone means by the files on that site. Reaching it previously meant listing every library and guessing which one by name, in whatever language the tenant was provisioned in.

Read one document library own metadata, including the storage quota. sharepoint_list_document_libraries returns the collection; this returns one, and the quota is what answers whether an upload will fit before sharepoint_upload_large_file finds out the hard way.

Read the LIST that backs a document library. A library is a list wearing a drive interface: the file actions take a drive id, the column, content-type and list-item actions take a list id, and nothing could convert one into the other — so an agent that had browsed a library could not ask what columns its documents carry. This is that conversion.

Read one library item metadata by id — name, size, type, who last changed it, and whether it is checked out. The pre-authenticated download URL Microsoft includes is removed: it returns the document bytes to anyone holding it with no sign-in, so it is a credential rather than a link.

Read one document activity as a SERIES over a window, rather than the all-time and last-seven-day totals sharepoint_get_file_analytics gives. It is the half that tells a person whether a document is still in use or was read once in March. ANOTHER WORKFORCE-MONITORING READ. Microsoft caps a daily-interval span at 90 days and rejects more.

Read how many people viewed and edited one document. Like the site-level equivalent this reports what staff have been looking at, and it is granted on its own terms rather than inside a general read tick.

Resolve a library-relative path to an item and read its details. The path-to-id bridge for the file plane: uploads address documents by path, so without this there was no way to ask whether that path already holds something before an upsert replaced it.

Read a document LIST-ITEM half — what the library own columns say about it: status, owner, review date, retention category, whatever the customer configured. For a records-managed library that is the part that matters, and no shipped action could read it. It also returns the sharepointIds facet, which carries the listItemUniqueId that the list-item analytics actions need.

Read ONE permission on a document. The singular of sharepoint_list_file_permissions, and the read that closes the loop on the sharing actions: creating a link or inviting someone returns a permission id, and until now nothing could look one up again to see whether it still exists or what it currently grants. Anonymous link URLs are removed from the result.

Read ONE version of a document by id — its size, when it was made and who made it. The singular of sharepoint_get_file_versions, and what makes sharepoint_restore_file_version checkable BEFORE it runs: restoring names a version id, and the only previous ways to see what that id referred to were to list the whole history and match by eye, or to download the entire document. The literal string current is a valid id and returns the live version. Pre-authenticated download URLs are removed from the result.

Read one document version history. Uploading is an upsert and is flagged destructive on exactly that basis; document libraries version by DEFAULT so the prior content usually survives, but until now Agentic Fabriq could not show that it did, or that it did not.

Read the ROOT folder item of a document library, which is the only way to obtain its id. Microsoft Graph refuses the literal string root as a parentReference id, so anything that has to name the library root as a destination — copying a file with no target folder is the obvious one — needs this first. There was no read that produced it.

Read one list own definition — its template, its display name, whether it is hidden. Answers what IS this list for an id that arrived from somewhere else (a search hit, a saved workflow, a person), where re-listing an entire site to find one row is not equivalent.

Read one list column definitions, including each column INTERNAL name. This is a prerequisite for writing: list items are addressed by internal name, which is not the display name a user sees — a column shown as Due Date is Due_x0020_Date, and a renamed column keeps its original internal name forever.

Read ONE list item by id, with its field values. Closes the read-after-write loop: creating and updating an item returns a body, but until now nothing could re-read that item to confirm the write survived, or follow a search hit that returned a list item id. Re-listing with a filter is not equivalent — filtering a non-indexed column is a hard error, not a slow answer.

Read how many people viewed and edited one list item, either as all-time and last-seven-day totals or as a series over a window. THIS IS A WORKFORCE-MONITORING READ WEARING A METRICS LABEL, like the site and file equivalents, and it is a separate action with a separate grant so it is decided on its own terms. It accepts either the ordinary list item id or the listItemUniqueId GUID, because Microsoft documents one placeholder for both.

Read a list item DRIVE-ITEM half — the file behind the row, with the id and drive id the file actions need. The inverse of sharepoint_get_file_list_item, and the bridge that makes downloading a document reachable from a list-item search. Only meaningful on a document library; on a plain list Microsoft Graph answers 404.

Read the SharePoint-native identifiers of one list item, including listItemUniqueId. Shipped specifically to unblock sharepoint_get_list_item_analytics: Microsoft Graph addresses list-item analytics by an id no other read produced, and a call whose argument no read can supply is not a shipped feature. It is also the id that copying a file into a content type default location requires.

Read the field values one list item held in a past version. The version list says a version exists; this says what it CONTAINED, which is what makes restoring it a decision rather than a gamble.

Read one site page, including its canvas layout and whether it is published or still a draft.

Read one horizontal section of a site page, with its layout and emphasis.

Read one column of one horizontal section of a site page.

Read a site page vertical section — the sidebar rail. There is at most one per page, so this takes no id, and a page without one answers 404, which is a real answer rather than an error.

Read ONE web part on a site page — a text part with its inline HTML, or a standard part with its type and data. This is the read that makes updating a web part safe: fetch it, change the one thing, send it back, instead of rewriting the whole page canvas and hoping nothing else was in it.

Read WHERE on the page one web part sits — which section, which column, which index. The inverse of reading web parts by position, and the missing half of it: without this, a caller holding a web part id cannot say where on the page it is, and therefore cannot place a new one beside it.

List the web parts at one position on a page — the targeted form of listing them all, for a page large enough that everything on it is not a useful answer.

Resolve the tenant root site collection. It is the one site whose address needs no prior knowledge at all — every other entry point needs a search term someone invented or a URL someone pasted — which makes it the reliable first call for an agent given nothing but a connection.

Turn the site URL a person can see in their browser (https://contoso.sharepoint.com/sites/marketing) into the composite site id Microsoft Graph works in. This is the bridge between what a user knows and what the API needs, and no existing Microsoft connector has an equivalent.

Read how many people viewed and edited content on one site, either as all-time and last-seven-day totals or as a series over a window. THIS IS A WORKFORCE-MONITORING READ WEARING A METRICS LABEL: it reports what staff have been looking at. It is a separate action with a separate grant precisely so it is decided on its own terms rather than acquired inside a general read tick.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.FullControl.All — full control of every site in the tenant). Read one application permission on a site.

Read one SITE own settings. Not to be confused with the tenant-wide SharePoint settings, which sit behind a separate administrator-only grant; this is per-site and costs nothing extra. BETA: Microsoft publishes no version 1.0 form, and the result says so.

NEEDS A NEW ADMIN CONSENT GRANT (SharePointTenantSettings.Read.All). Read the tenant-wide SharePoint and OneDrive settings. THIS IS THE READ THAT ANSWERS A QUESTION THE CONNECTOR OTHERWISE HAS TO GUESS: the sharing capability setting says whether anonymous external links are even possible in this tenant, which every sharing decision here currently has to assume the permissive case about. It also answers whether site creation is enabled and where new sites go. BE CLEAR WHAT IT DISCLOSES: the tenant entire external-sharing posture, its allowed and blocked sharing domains, and its idle-session policy — administrator-grade information, which is why it sits behind its own grant. The matching WRITE permission is deliberately never requested, because one call on it toggles anonymous external sharing for the whole tenant.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). Read one term, including its localised labels.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). Read one term group.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). Read one term set.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). Read the managed-metadata term store own settings — its identifier and the languages it carries. The root of the taxonomy dependency chain: nothing else in this family is reachable without it. The store is ADDRESSED through a site but is not scoped to one.

DESTRUCTIVE — grant named people durable access to a document or folder. NO EMAIL IS SENT AND THAT IS NOT A DEFAULT, IT IS THE SHAPE OF THE ACTION: Microsoft option to mail the recipient sends from the signed-in user own mailbox to an address the agent chose, with an agent-authored message, and that outward step is deliberately not exposed. The GRANT is — the recipient is a named principal who must sign in, and sharepoint_delete_file_permission takes it back. Recipients find the document under Shared with me. Whether an address outside the organisation is accepted is a tenant setting this connector cannot read. PASSING retain_inherited_permissions=false ALSO REQUIRES confirm_permission_reset='remove-all-existing-permissions' — it wipes every permission the item already carries and is a separate decision from confirm.

NEEDS A NEW ADMIN CONSENT GRANT (Sites.FullControl.All) even though it is a read — Microsoft gates it at the same tier as the publish it precedes, which was checked rather than assumed. It is the precondition read that makes publishing and unpublishing usable rather than guesswork.

List the whole ancestry of one content type, nearest ancestor first. The parent read answers who is the parent; this answers what is the whole chain, which is what shows a sealed or read-only ancestor several levels up — the thing that will refuse a write for a reason the immediate parent does not reveal.

List the column LINKS on a content type — the association rows, not the definitions. This is where a column inherited from a parent content type is distinguishable from one added locally, and only the second kind can be removed. Without it, an agent can see a content type columns but cannot tell which of them a schema change is even allowed to touch.

List a content type columns IN THE ORDER they are presented on the form. Column order is the whole content of this read and is not recoverable from the unordered columns list. For a form people fill in every day, order is the difference between a usable content type and a merely correct one.

Read the columns belonging to one content type, each with the INTERNAL name a write must use and whether it is required. The third of the three column views, and the one that answers what a document of a given TYPE has to carry — which is the question that actually blocks a write into a records-managed library.

List the content types on a site, or the ones associated with one list. A content type is the template a list item or a document conforms to, and records-managed libraries are almost entirely content-type driven — so an agent writing into one without this is guessing at a schema that is enforced.

List one site document libraries, each with the drive id that file actions require. Overlaps microsoft_onedrive_list_sharepoint_site_drives deliberately: a drive id is not guessable and a SharePoint connection cannot borrow OneDrive copy of this call.

Read the document-set version history of one library item. A document set versions a whole folder of documents together, which is how records-management libraries capture the state of a matter on the day it was filed. An empty result means the item is not a document set, which is the usual case outside records management.

Read what changed in one document library since a previous point, including DELETIONS. The file-plane twin of the list delta, and it carries the same argument: a re-listing cannot see what was removed.

Read WHO can reach one document and at what role, including whether an anonymous sharing link exists on it. A READ ONLY — creating a sharing link, inviting someone and removing access are all deliberately absent, and Microsoft Graph would accept every one of them with the permissions this connector already holds; the exclusion is a judgement, recorded in docs/coverage/sharepoint.md. This ships because it is the diagnostic that makes the exclusion workable: is this document shared outside the company becomes answerable. Anonymous link URLs are removed from the result, because such a URL returns the document to anyone holding it with no sign-in.

List the thumbnail sets SharePoint has rendered for one item. Identification and diagnostic value rather than display value: a thumbnail existing says SharePoint has processed the document, and its absence on a file that should have one is a real signal. The thumbnail URLs are themselves pre-authenticated and are removed.

List the files and folders inside one document library folder, each with the item id needed to read or delete it. This closes a real dead end: microsoft_onedrive_read_sharepoint_file needs an item id that, until this action existed, nothing in Agentic Fabriq could produce. Folder and file names are customer content.

List the sites the SIGNED-IN USER follows. The one entry point that needs no prior knowledge and is specific to the person asking — searching the tenant returns everything and the root site is the same for everybody, while this answers the sites I actually work in, which is very often what a person means by my SharePoint. BETA.

Read what changed in one SharePoint list since a previous point, including DELETIONS. This is the core agent-over-a-tracker workflow and the reason SharePoint lists are worth reaching at all: a full re-listing cannot express since I last looked, and — the part that matters — a re-listing cannot see a row that vanished.

Read one list item version history — who changed it and when. The direct mitigation for this connector own stated risk: updating a list item is flagged destructive because on most lists the previous value is simply gone, and where versioning IS enabled Microsoft Graph has the history. An empty history is itself the answer: it means versioning is off and the destructive flag is being literal.

Read who can reach ONE list item and at what role. Item-level permissions are how SharePoint models a register whose rows are not all visible to everyone — an HR case list, an approvals queue — so this is a fact about a list item rather than a duplicate of the file read. Anonymous link URLs are removed.

Read items (rows) from one SharePoint list with their field values, optionally narrowed by an OData filter. The values returned are customer record data, so granting this exposes the contents of whichever lists the signed-in user can already read.

List the long-running operations SharePoint is running on one list, with their status. Diagnostic read.

Read which APPLICATIONS have been granted access to one list, and at what role — the Sites.Selected model ledger for a single register. Worth knowing that this needs only Sites.Read.All, unlike the site-level equivalent, which Microsoft gates at full control of the whole tenant. It discloses no document content.

List the SharePoint lists and document libraries on one site, each with its id and template type. SharePoint lists are where non-document content lives — registers, trackers, issue logs, approvals, asset inventories — and no existing Microsoft connector can see them at all.

List the web parts inside one column of one section of a page. A text web part carries its content inline, so this is how the words in one part of a page are read without fetching the entire canvas.

List a site page horizontal sections — the rows of its layout, top to bottom, each with its column arrangement and background emphasis. The entry point for editing a page surgically instead of replacing its whole canvas.

List the columns inside one horizontal section of a page. A section is divided into twelve grid units and each column records how many it spans, which is what makes a layout change predictable rather than a surprise.

List the PAGE TEMPLATES available on one site. Creating a page makes a blank article; real intranets standardise on templates, and an agent that cannot see them will produce a page that looks nothing like every other page on the site. BETA.

List the web parts in a site page vertical section.

List the web parts on one site page. Text web parts carry their content inline, so this is how a page words are actually read.

List the site pages on one site, including news posts. Modern SharePoint intranets are pages and news, not only lists and libraries — search could already RETURN a page as a hit and nothing could read one. There is no separate News API: a news post is a page whose promotion kind says so.

List what is in one site first-stage recycle bin — name, size, when it was deleted and where it was deleted from. THE HONESTY FIX FOR EVERY DESTRUCTIVE ACTION HERE: deleting a list item, a file or a page all say Agentic Fabriq cannot undo this, which is true because Microsoft Graph exposes no restore, and until now they could not even show where the deleted thing went. This turns it is gone and I cannot help you into it is in the recycle bin, here is its name, ask a site administrator. Uses Microsoft BETA endpoint, because Graph publishes no v1.0 form of it; it is the only beta call in this connector.

Read the SITE-level column definitions — the reusable field definitions a content type is assembled from. Distinct from the list-level columns read: this is what answers what fields this site information architecture actually has, before anything is written.

List the columns a site INHERITS from its parent hierarchy, as opposed to the ones defined on it. This is where a hub site standard metadata lives, so without it a caller looking at a spoke site sees a column set missing everything the hub contributed. BETA.

List the long-running operations SharePoint is running on one site, with their status. A diagnostic read: SharePoint performs several operations asynchronously and answers immediately, so without this an agent that started one has no way to learn whether it finished, and neither does the person who asked.

NEEDS A NEW ADMIN CONSENT GRANT, AND IT IS THE LARGEST ONE AVAILABLE HERE (Sites.FullControl.All — full control of EVERY site in the tenant). Microsoft offers no lower tier for this endpoint. It reads which third-party applications have been granted access to a site and whether they can write, which is a genuinely useful security-posture answer — but the permission needed to ask the question is larger than the answer, and an operator who does not enable this grant simply does not get this action and loses nothing else. Microsoft does not support listing a subsite permissions.

Search the SharePoint sites this account can reach and return each one with the composite site id (host,siteGuid,webGuid) that every other SharePoint action requires. This is the starting point: no other action accepts a site name, and a site id must never be guessed. Overlaps microsoft_onedrive_list_sharepoint_sites deliberately, because a SharePoint connection cannot call a OneDrive connection.

List the subsites directly beneath one site. Site search does not reliably surface subsites, and a migrated on-premises estate is very often a subsite tree rather than a flat set of site collections — so without this, whole branches of a customer SharePoint are unaddressable, because a site id cannot be guessed.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). List the child terms of one term. The descent step — without it the taxonomy is only ever one level deep, which for a real corporate vocabulary such as Region then Country then City is most of it missing.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). List the groups in the term store — the top level of the taxonomy, such as Departments, Locations or Products. Each group scope says whether it is global to the tenant, system-managed, or limited to one site collection, which is the only thing that tells a caller how far a change inside it will reach.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). List which terms are pinned or reused into a set or a term. This explains why a term appears in a vocabulary it was not created in: a pin means the hierarchy is mirrored from elsewhere and can only be edited at its origin, a reuse means it can be edited from either place. Editing a pinned term from the wrong end fails for a reason nothing else would show.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). List the term sets inside one group. A term set is the vocabulary a single managed-metadata column draws from, so this is what turns which taxonomy is this column using into an answerable question.

NEEDS A NEW ADMIN CONSENT GRANT (TermStore.Read.All). List the TOP-LEVEL terms in a term set. Terms are a tree and this returns the first level; use the children read to descend. Microsoft publishes no operation that flattens the tree.

DESTRUCTIVE — move and/or rename a document or folder within one library. The harm is not data loss: a move relocates a document OTHER PEOPLE hold links to, and every existing link, embed and recent-files entry pointing at the old path stops resolving with nobody but the agent knowing why. Moving a folder moves everything beneath it. Reversible by moving it back. Microsoft cannot move an item between libraries at all — copy, then delete, in that order.

DESTRUCTIVE, AND THE ONLY ACTION HERE WITH NO INVERSE ANYWHERE IN MICROSOFT GRAPH. This is a DIFFERENT operation from the ordinary delete and it is a separate row on purpose: the ordinary delete goes to the site recycle bin, where an administrator can restore it for 93 days; this one bypasses the recycle bin entirely and the document cannot be restored by an administrator, by the second-stage recycle bin, or by Microsoft support. It requires an explicit confirm flag, because an agent assembling arguments from a sentence can otherwise confuse the two actions, which differ only in their name.

DESTRUCTIVE BY REACH RATHER THAN BY LOSS, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.FullControl.All). Publishing makes a hub content type available for EVERY SITE IN THE TENANT to pull down, and pushes it to sites that have already subscribed. Nothing is deleted; what changes is how many places the schema now exists in, and that number is not knowable in advance. The site must be the content type hub — publishing from an ordinary site is refused. Its inverse ships in this same migration.

DESTRUCTIVE by intent rather than by data loss — publish a page draft to everyone who can see the site, which for an intranet home site is the whole organisation. MICROSOFT GRAPH PUBLISHES NO UNPUBLISH OPERATION, in v1.0 or in beta, so the only way back is to delete the page. Where a page-approval flow is configured, publishing is queued for approval instead and the response does not distinguish the two — read the page back to see which happened.

DESTRUCTIVE, AND WIDER THAN ANY OTHER RESTORE HERE — it rolls back EVERY document in the set, not one file. Like the other restores it destroys nothing, because the content it replaces stays in each document own history, but the blast radius is a folder rather than a file. Read the version list first to see what is being restored to.

DESTRUCTIVE, AND IT DESTROYS NOTHING — the undo for uploading over an existing document. Restoring ADDS a new current version and the content it replaced stays in history, so no content can be lost by calling this and calling it by mistake is undone by calling it again. Shipping the upload upsert without this was the asymmetry worth fixing.

DESTRUCTIVE, AND IT DESTROYS NOTHING — the undo for updating a list item. Restoring a version puts the old field values back by ADDING a new current version, so the values being replaced remain in history and calling this by mistake is undone by calling it again. It is a net risk reduction: it converts the update action from a one-way door into a reversible one wherever the list has versioning enabled.

Search across sites, lists, list items and library files with Microsoft Graph search. Results carry document titles and content extracts, so this reaches the substance of documents rather than only their names. Scoped to SharePoint entity types only — mail, calendar and Teams content are deliberately excluded.

Search inside ONE document library, or one folder of it, matching across filename, metadata AND file content. Different from sharepoint_search, which is tenant-wide and returns hits from every site the signed-in user can reach; this is what someone means by find the Acme contract in the Legal library.

Reactivate an archived site. THE INVERSE OF ARCHIVING, and it restores write access. SharePoint reactivates asynchronously, so success means accepted rather than already writable; the site operations read shows progress. BETA.

Stop following a site. The inverse of following one, and it removes a navigation entry rather than any access. BETA.

DESTRUCTIVE, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.FullControl.All). The inverse of publishing, but NOT A CLEAN UNDO: sites that already pulled the content type down KEEP their copies. Unpublishing stops distribution; it does not retract what was distributed.

DESTRUCTIVE, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). A column definition is the contract every existing item in the list already conforms to. Narrowing a text column length, or removing a value from a choice column list, leaves rows holding data the schema now calls invalid, and SharePoint does not migrate them. Making a column required retroactively makes every existing row that lacks the value fail its next save. At content-type scope Microsoft allows only required and hidden to change.

DESTRUCTIVE, AND NEEDS A NEW ADMIN CONSENT GRANT (Sites.Manage.All). One property in particular is why: propagating changes pushes this edit down into every inherited content type and every list that implements it, all at once, across the site — the difference between editing one object and editing an unknown number of them. Sealing a content type makes it unmodifiable by anyone and only a site collection administrator can unseal it, so that flag is effectively one-way from here.

Update a document DESCRIPTION and its filesystem timestamps. Deliberately narrower than the Microsoft Graph call behind it: renaming and moving are refused here and belong to sharepoint_move_file, which resolves the library root id Graph requires and carries the warning that relocating a document breaks every link, embed and recent-files entry other people hold. Backdating the created or last-modified timestamp REWRITES RECORDED HISTORY and SharePoint then reports it as fact everywhere, including in retention and audit views.

DESTRUCTIVE IN BOTH DIRECTIONS — change the role on one existing permission. Widening read to write hands out edit access; narrowing write to read can stop somebody mid-task without warning them. Only the role is changeable, so an expiry cannot be adjusted after the fact — remove the permission and make a new one. Microsoft also refuses this call on organisational and people sharing links.

DESTRUCTIVE — overwrite field values on one existing list item. SharePoint keeps item version history only when the list has versioning enabled, which is not the default for a generic list, so on most lists the previous value is gone and Agentic Fabriq cannot restore it. The wrong item id overwrites the wrong record.

DESTRUCTIVE — change a site page title or content. The canvas layout IS A FULL REPLACE, not a merge: sending a layout containing one section deletes every other section on the page, and Microsoft does not warn. Read the current layout first and send it back modified. Changes land in the page draft and are not visible to readers until it is published.

DESTRUCTIVE, and for a specific reason rather than a ceremonial one: NARROWING A SECTION LAYOUT DROPS THE COLUMNS THAT NO LONGER FIT, AND EVERY WEB PART IN THEM GOES WITH THE COLUMN. Changing a three-column section to one column is a content deletion wearing a formatting label. Read the section columns first.

DESTRUCTIVE only in the weakest sense — it changes how a published page looks to everyone who can see the site, and nothing is lost. Flagged for consistency with the other page-canvas writes: an agent that has to think about one of them should think about all of them.

DESTRUCTIVE — the body REPLACES the web part content rather than merging into it, so a partial data object loses whatever was not sent. Read the web part first and send it back modified. It is the same hazard the whole-page update has, one level down and with a far smaller blast radius, which is the point of shipping it.

DESTRUCTIVE AND TENANT-WIDE, AND NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). THIS IS THE ONE WHOSE REACH IS LEAST OBVIOUS: renaming a term re-labels the managed-metadata value on every item across every site that used it, because items store the term identifier and render its current label. A report that read EMEA yesterday reads whatever you type today, in every library at once, with no per-site override and no notification to anyone.

DESTRUCTIVE AND TENANT-WIDE, AND NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). A term set name is what people see in the column picker on every site that uses it. Renaming does not break stored values, which are bound by identifier rather than by name, but it changes the label everywhere at once and there is no per-site override.

DESTRUCTIVE AND TENANT-WIDE, AND NEEDS A NEW ADMIN CONSENT GRANT (TermStore.ReadWrite.All). The widest write in the taxonomy family: removing a language tag makes every localised term name in that language unreachable, across every site in the tenant at once, and there is no per-site version of this setting to limit it. Sending a shorter list of language tags REMOVES the ones left out.

DESTRUCTIVE — upload a file into a document library folder. Microsoft Graph simple upload is an UPSERT: a file already at that path is REPLACED rather than rejected. Document libraries version by default so the previous content usually survives in history, but a library with versioning off loses it. Goes beyond microsoft_onedrive_write_sharepoint_file, which can only write to the library root.

DESTRUCTIVE when conflict_behavior is replace — upload a document through a resumable, chunked upload session, which is the only supported way past Microsoft 250 MB simple-upload ceiling. The default here is FAIL rather than the plain upload silent upsert: a large upload is exactly where I did not realise it would overwrite is most expensive, so replacing has to be asked for by name. A failed session is cancelled rather than left holding partial content.