Salesforce

Add a record, list view or report to the connected user's own favorites. It changes a personal navigation shortcut and no business data, and it is fully reversible by the action that removes one, which is granted separately and ships alongside it.

Search across objects with a separate field list, filter, sort and limit FOR EACH OBJECT — 'find Acme, returning the account's owner and the five most recent open cases' is one call here and three otherwise. The richer form of the parameter search, which applies one field list and one limit to everything it searches. Read-only: the per-object filter is a query fragment and the query language Salesforce uses for it cannot insert, update or delete.

Ask Salesforce to run YOUR OWN assignment rules over one Lead or Case and route it to the owner those rules choose. Routing a lead is the most common thing an automation does after creating one, and until now an agent could only set the owner to an id it had chosen ITSELF — which is the agent substituting its judgement for your routing policy. This asks the organisation instead. It is a write and it goes through the same sObject deny-list every other write does. Restricted to Lead and Case because Salesforce silently IGNORES the request on any other object, and an action that silently does nothing is worse than one that refuses. Reversible: the previous owner is on the record and the update action sets it back. It may fire your org's own assignment notification email, which is your configured behaviour rather than a message Agentic Fabriq composes.

Copy an existing report into a new one, leaving the original completely untouched. This is the SAFE way to change a report and the reason it is granted separately from rewriting one: an agent asked to 'adjust the pipeline report to exclude renewals' should clone and edit the clone, so the report the organisation actually reads keeps answering the question it always answered. It is also the inverse pair of deleting a report.

Create one Salesforce record. Nothing existing is overwritten and the record can be deleted afterwards, so this is not marked destructive — but it is not free of consequences: Salesforce runs validation rules, assignment rules, workflow, flows and Apex triggers on insert, so creating a Case or a Lead can send email to a real person the moment it exists. Run salesforce_describe_sobject first; required fields and picklist values differ per org. Identity and org-configuration objects (User, Profile, PermissionSet and the like) cannot be created through Agentic Fabriq.

Create a parent record together with its child records in one call — an account with its contacts, an opportunity with its line items — up to 200 records in total across a maximum of five levels and five object types. Salesforce rolls the entire tree back if any part of it fails; there is no partial mode. Nothing existing is overwritten, so this is not marked destructive. Every object named anywhere in the tree is checked against the same restrictions as a single create: identity, access-control and org-configuration objects cannot be created at any level, not just at the top.

Create up to 200 records on one object in a single call. This closes an asymmetry that was backwards on safety: Agentic Fabriq previously shipped the batched UPDATE — which overwrites — and not the batched create, so importing 200 leads cost 200 separate requests against the org's shared 24-hour allocation. Nothing existing is overwritten and every created record can be deleted, so this is not marked destructive; it is not free of consequences, because Salesforce runs validation rules, assignment rules, workflow, flows and Apex triggers on each insert, so 200 new Cases can send 200 emails to real people. The whole batch rolls back if any record fails unless that is explicitly disabled.

Remove one favorite from the connected user's list. NOT marked destructive, and that is a deliberate distinction rather than an oversight: every other delete in this connector removes something only the Recycle Bin can return, and this removes a personal navigation shortcut that the add action puts straight back.

DESTRUCTIVE — delete one Salesforce record. It goes to the org's Recycle Bin and can be restored for 15 days ONLY if the bin has not been emptied and the org has not exceeded its bin capacity, after which Salesforce purges it automatically. Deleting a parent also cascades to children configured for cascade delete, so one call can remove records you never named. There is no undo beyond the bin. Salesforce uses the same permission for reading and deleting, so granting this action separately is the only separation Agentic Fabriq can offer.

DESTRUCTIVE — delete one record identified by the id it carries in ANOTHER system rather than by its Salesforce id, matched on a field marked External ID. Completes the external-id set: reading and creating-or-updating by external id already existed and deleting did not, so a caller holding only the external key had to look the record up first and then delete it by a different identifier. The record goes to the org's Recycle Bin and can be restored for 15 days ONLY if the bin has not been emptied and the org has not exceeded its capacity. Deleting a parent also cascades to children configured for cascade delete, so one call can remove records you never named. This action requires an explicit confirmation argument in addition to being granted, because the record is addressed by a key that is not a Salesforce id and cannot be checked by eye.

DESTRUCTIVE — delete up to 200 records in one call. They go to the org's Recycle Bin and can be restored for 15 days ONLY if the bin has not been emptied and the org has not exceeded its capacity, after which Salesforce purges them. Deleting a parent also cascades to children configured for cascade delete, so one call can remove records you never named — 200 times over. This action requires the object name even though Salesforce's own endpoint does not: a batch delete identifies records by id alone, and without the object name Agentic Fabriq could not tell an account batch from a user batch. Every id is verified against that object before anything is deleted.

DESTRUCTIVE — delete a saved report. The report goes to the Recycle Bin, but every dashboard component built on it breaks immediately and the people who read those dashboards find out when the dashboard is empty. Nothing in Agentic Fabriq can tell you in advance which dashboards those are. This action requires an explicit confirmation argument in addition to being granted.

Return one dashboard's metadata: its components, filters and layout, and which report backs each component. Read-only.

Return the page layouts the org actually puts in front of humans — the full layout, the compact highlights panel, approval layouts, or a specific named layout. Describing an object tells you what fields it HAS; this tells you which of them the org considers worth showing, which is a much better default field set for a summary than 'every column'.

Return one list view's columns, filters and the query Salesforce runs for it. The query is the useful part: an agent can read the org's own definition of 'at risk' and then extend it in a SOQL query, rather than guessing at what the label means.

Return one quick action's layout, target object and fields. Read-only, for the same reason as listing them.

Return one report's columns, groupings and filters. This is what makes a report's output interpretable: a report result is a nested fact map keyed by column and grouping identifiers that mean nothing without this.

Return one Salesforce object's fields with their API names, types, lengths, picklist values, and whether each is required, createable or updateable. RUN THIS BEFORE ANY WRITE: field API names differ from their labels, required fields and picklist values differ per org, and guessing produces an error that has already consumed one of the org's API requests.

Return one Tooling object type's fields. A describe returns the SHAPE of a type and never a stored value, which is why it is available for every Tooling type including the ones whose records cannot be read.

Ask Salesforce whether a record you are about to create already exists, using the org's OWN duplicate rules. It creates nothing and changes nothing. This is the missing precondition for creating records in bulk, which is the most common CRM agent task and whose most common damage is duplicate contacts — damage Agentic Fabriq cannot undo, because merging records is not something the REST API offers. The organisation already owns the definition of 'the same person'; this asks it rather than guessing.

Return one Lightning app's metadata and navigation bar — or, with no app id, the app the connected user last selected or sees by default. TWO Salesforce resources behind ONE action, because the second is the first with a fixed word in place of the id. Leaving the id out is the orientation read for an agent asked to do something 'here': which application the person is in decides which navigation items and which list views are the relevant ones.

Download the contents of a binary field — an attachment's body, a file's version data — returned base64 encoded with its size and content type. Agentic Fabriq refuses files above a fixed ceiling, because the contents pass through the tool result and into the agent's context window, and base64 inflates them by a third. The size is named in the refusal so a caller knows why.

Read one Chatter group's information — its name, description, membership count and visibility. Read-only.

Read one Salesforce user's profile — name, title, manager, contact details — defaulting to the connected user. This is NOT the identity scope by another name: Agentic Fabriq deliberately does not request Salesforce's `id` scope, and this returns the org's own user record rather than identity-service claims. It is what a summary needs when it has to say who owns a record.

Read one Experience Cloud site's information — its name, status, URL and description. Read-only.

Read one file's metadata — title, owner, type, size and version history — WITHOUT downloading it. The distinction is the point: the bytes come from the file-download action, which refuses anything over a fixed ceiling because the contents pass into the agent's context window. This is the call that tells an agent how big a file is before it asks for it.

Read the organisation's Connect-level settings and branding. Read-only reference data.

Ask whether specific people have consented to one kind of processing — being emailed, tracked, geo-tracked, profiled, solicited. Salesforce aggregates this across Individual, Contact, Lead and the rest and returns a single answer, which is the whole point: an agent that decides to send because a field looked empty has made a decision the organisation already recorded an answer to. Read-only, and arguably the call that should precede any outbound action.

Return one dashboard's components and the results they last computed — which may be hours old, because a dashboard shows a cached snapshot until somebody refreshes it. Refreshing is a separate action.

Report whether a dashboard refresh has finished. This closes a hole that was shipped knowingly: refreshing a dashboard is ASYNCHRONOUS and answers immediately, so without this an agent that refreshes and then reads gets the stale snapshot and presents it as current. Read-only and cheap.

Return one data category's child categories and the number of articles filed under each. Read-only reference metadata for navigating a Knowledge taxonomy.

List the ids of records DELETED in a time window, with each one's deletion date. The other half of incremental sync: without it, a downstream system cannot tell a deleted record from one it simply did not see. Salesforce limits the lookback to 15 days, which is the same 15 days the Recycle Bin holds — after that the record is gone and so is the record of its deletion.

Return the org's duplicate-matching configuration for one object — which matching rules an administrator defined and what they compare. Read-only, and it is what makes a duplicate check's result interpretable rather than a bare list of ids.

Return the schema of a platform event or change event. This is the audit read behind one of Agentic Fabriq's own restrictions: PUBLISHING a platform event is refused, because in Salesforce creating an event record IS publishing it and a published event triggers Apex, flows and every external subscriber. Reading the definition is not refused — an administrator asking what an agent would have been able to fire needs the schema to answer.

Read the comments on one feed element, with paging. Read-only; commenting is not offered, for the same reason posting is not.

Read one feed element — a post, a shared link, or a tracked field change — by its id. Read-only.

Return the actions in the org's global actions menu — the plus menu — with their metadata. READ ONLY, and the absence of an invoke counterpart is deliberate rather than an omission: a quick action names its target object in its own DEFINITION rather than in the call, so invoking one is a create or update on an object Agentic Fabriq's write deny-list never sees. Listing them is how an operator audits what the org exposes.

Read one Knowledge article in full, including its body and its data categories. Read-only, and it returns the PUBLISHED version — the one a customer would be shown — rather than a draft.

Report the Salesforce org's current limit consumption, above all DailyApiRequests. Salesforce meters a rolling 24-hour ORG-WIDE request allocation shared by every integration connected to that org, and exhausting it returns 403 REQUEST_LIMIT_EXCEEDED for hours with no way to reset it. Call this BEFORE a bulk operation, not after.

Return an object's list views as metadata alone, with a SEARCH TERM and a recently-used filter the other list-view actions have no parameter for. On a customised org with two hundred Account list views, 'the one with renewal in the name' is the only usable way in. Read-only.

Return the metadata for several list views in one request. Read-only.

Return one list view's records without its layout metadata, with paging. The cheap half of the list-view display action, for paging through a list an agent has already inspected once.

Return an object's list views, or one list view together with the columns the org displays and the records formatted against them. This deliberately overlaps with the plainer list-view actions and is not a duplicate of them: those return the REST API's shape — ids, the underlying query, raw rows — and this returns what a person sitting in Salesforce would see. An agent asked to reproduce a list the way a colleague sees it needs this one.

Return the header actions on one or more list views. Read-only.

Return one record's translated field values. In a multi-language org the stored value and the value a user reads are different strings, and a summary built on the stored one is wrong in a way nobody notices until a customer reads it. Read-only.

Return which objects a lookup or relationship field may point at, and how the org filters what qualifies. A polymorphic lookup can target several objects, and an administrator's lookup filter can narrow which records are acceptable. An agent that sets a relationship field by guessing an id is the write that fails with a message about an invalid cross-reference; this is the read that prevents it.

Search the records a specific lookup field would actually accept, honouring the org's lookup filter. This is the id-producing read for every relationship write in this connector — until now the only way to fill a lookup was a general query that did not know about the field's filter, so an agent could find an id, set it, and be rejected. A write whose arguments no read can supply is not a shipped feature; this closes that for the whole relationship surface at once.

Return the 'Recently Viewed' records for one object, rows only, with paging. Read-only and cheap.

Return the 'Recently Viewed' list for one object together with its display columns. Salesforce models this list as its own resource rather than as a saved list view, so it needs its own action. It pairs with the recently-viewed records action: that one answers which records, this one answers which records in the columns this org shows.

Ask about several kinds of consent for several people in ONE request. Read-only, and cheaper than one call per action against the org's shared allocation.

Read the connected user's own Chatter news feed. Read-only, and bounded by what that user can already see. Posting is not offered.

Return the actions the org offers for one or more objects on a named surface: 'lookup' is the record picker on a lookup field, where the org may let a person create the missing record inline, and 'mru-list' is the header of the object's 'Recently Viewed' list. TWO Salesforce resources behind ONE action, because both are addressed by object names and differ only in a fixed part of the address — the same way the layout describe covers four resources through one 'layout_type' argument. READ ONLY, and the absence of an invoke counterpart is deliberate: a quick action names its target object in its own definition rather than in the call, so invoking one is a write Agentic Fabriq's deny-list never sees.

Return one object's user-interface metadata: the org's own labels for it, its key prefix, and its record types. Smaller than a full field describe and it carries labels rather than API names, which is what an agent needs when it is talking to a person. It is also the only action that produces a RECORD TYPE ID, which the picklist actions require.

Report whether one Salesforce user's password has expired. READ ONLY, and the distinction from the operation Agentic Fabriq refuses is the whole reason this is offered: SETTING or RESETTING a password on the same Salesforce sub-resource is full account takeover inside your org from a CRM tool grant, and Agentic Fabriq offers no action that does it. This one returns a single expiry flag. It hands over no credential, reveals no password and changes nothing. The user object in the path is fixed in Agentic Fabriq's code rather than taken from the call, so this read cannot be aimed at another resource.

Return the values one picklist field accepts for one record type. This is the fix for the most common silent write failure against Salesforce: describing an object returns the field's GLOBAL value set, and Salesforce filters picklist values per record type, so a describe will happily show a value the record you are about to create cannot use. The write is rejected, the agent guesses again, and the org's API allocation pays for both attempts.

Return the values EVERY picklist field on an object accepts for one record type, in one request. The batched form of the single-field lookup, for an agent about to build a whole record rather than set one field.

Return the field values a quick action would pre-fill. READ ONLY, and it completes the read side of a surface Agentic Fabriq deliberately never runs: a quick action writes to an object named in the action's own DEFINITION rather than in the call, so the restrictions that stop a write reaching an identity or configuration object would not be able to see it. Being able to inspect what an action would do is how an administrator audits what the org has exposed.

Read one Salesforce record by its 15- or 18-character id. Name the fields you need: omitting them returns every field the connected user may see, which on a customised Account can be several hundred columns of customer data.

Return the actions the org displays for one or more records on a named surface — the record page ('detail'), the edit screen ('record-edit', which Salesforce answers with a DIFFERENT set), one related list on the page ('related-list'), or a user or group photo ('photo'). FOUR Salesforce resources behind ONE action, because all four are addressed by record ids and differ only in a fixed part of the address. READ ONLY: this answers 'what could I do with this record' in your org's own vocabulary, and Agentic Fabriq offers nothing that fires one of the actions it lists, because a quick action names its target object in its own definition rather than in the call and so would be a write the deny-list never sees.

Read one record using the id it carries in ANOTHER system — an ERP number, a billing account reference — rather than its Salesforce id, matched on a field marked External ID. The read that makes an upsert safe to reason about: it answers 'does Salesforce already know this' without a query and without guessing.

Report approximate record counts for named objects, or for every object the org counts, in ONE request — where the query equivalent is one count per object. Approximate by design: Salesforce serves it from internal statistics rather than counting rows, so treat it as an order of magnitude. It is the call that tells an agent whether 'update every contact' means 40 records or four million, before it starts.

Return the field values and layout a NEW record of this type would start from — what the org pre-fills, which fields are required, which are read-only on create. It reads only and creates nothing. This is the check that turns a rejected create into a correct one on the first attempt, which matters because a failed create still spends one of the org's API requests and may still have fired validation rules.

Read the Chatter feed attached to one record — the posts, comments and tracked field changes on it. Worth having because the feed is very often where the DECISION behind a record was actually made: the record says the opportunity closed lost, the feed says why, and who agreed. READ ONLY. Agentic Fabriq offers no action that posts to Chatter, because a post is visible to the whole org and is not recallable once notifications have fanned out.

Read up to 200 records together with the layout the organisation actually displays them in — which fields, in what order, under what labels, with picklist values already resolved. This answers a question that describing an object cannot: a describe lists every field that EXISTS, which on a customised Account runs to several hundred, while this lists the ones the org decided are worth showing. For summarising a record it is a far better default than 'every column', and it costs one request rather than two.

Read up to 200 records by id in ONE API request instead of 200. Directly in service of the constraint that matters most for Salesforce: the org meters a rolling 24-hour allocation shared by every integration connected to it, and an agent looping over query results is the fastest way to exhaust it. The field list is required rather than optional here, which also avoids returning every column the connected user may see, multiplied by 200.

Read several records that belong to DIFFERENT objects in one request. This is not a duplicate of the existing multi-record read: that one addresses a collection of a single object type and every id in the batch must belong to it, which is why the batch delete has to check key prefixes. This takes a mixed bag of ids, which is the shape an agent actually holds after a SOSL search or after reading a feed — and which it would otherwise have to sort by key prefix and fetch in one call per object.

Return one related list's DISPLAY definition on a parent object — its columns, its sort, its label. Describing an object returns every child relationship the schema has, which on a customised Account runs to dozens; this returns the one the org actually puts on the page. Same distinction the list-view display action draws against the plainer list-view metadata.

Return the connected user's own display preferences for one related list — column widths, text wrapping, ordering, sort. Personal display state; no business data. Read-only, and it is the read that makes the paired write reversible, because it returns the values to put back.

Return the display preferences for several related lists in ONE request against the org's shared 24-hour allocation, where the single-list form is one request per list.

Return one related list's records in the columns the org displays, with paging. Overlaps deliberately with the plainer related-records action and is not a duplicate of it: that one traverses the relationship through the REST API and returns its shape, and this returns the related list the way the page renders it. An agent asked to reproduce what a colleague sees needs this one.

Return the child records on one relationship — the contacts on an account, the opportunities on a lead. This replaces a hand-composed SOQL parent-child subquery, which is the highest-error-rate thing an agent does against Salesforce: the relationship naming rules differ between standard and custom objects and the grammar is easy to get subtly wrong. Read-only, and bounded by the same field-level security and sharing rules as every other read. Use 'Describe an object's fields' to see which relationship names exist.

List the filter operators valid for each field type in a report. Reference metadata; read-only and cheap.

Collect the results of a report that was queued rather than run synchronously — the right shape for a report large enough to time out. Salesforce retains an instance for a limited window and then discards it, so a report queued and never collected has spent one of the org's API requests for nothing.

Download an image embedded in a rich text field, returned base64 encoded with its size and content type. Agentic Fabriq refuses anything above a fixed ceiling, because the contents pass through the tool result into the agent's context window and base64 inflates them by a third. An image is exactly the payload that is large without looking it.

Return the columns the org shows in search results for each named object. Useful for rendering a search result the way the org's own users would recognise it.

Return the objects the connected user searches most often, in Salesforce's own ranking. It answers 'which objects does this person actually work in', which is a far better default for an unqualified search than every object in the org.

Return record suggestions for a partial search term, as the platform's own search box does. The point for an agent is disambiguation: 'the Acme account' is often three accounts, and this is the cheap call that finds that out before a write picks one of them at random.

Return one object's summary metadata — its label, key prefix and whether it is createable, updateable and deletable — plus the records of that type the connected user viewed most recently. Far cheaper than a full field describe, which on a heavily customised Account runs to hundreds of kilobytes, and enough for the common question, which is 'does this object exist in this org and may I create one'. The recent-items half is a free source of record ids.

Return the org's own icon and colour for each object. Useful when rendering a summary in the org's visual language rather than an invented one. Read-only.

Read one Tooling record by id — an Apex class, a flow, a validation rule. Read-only. Reading the types whose configuration can contain stored credentials — named credentials, external data sources, connected applications, certificates, single sign-on configuration — is refused, because that configuration can carry authentication material and Salesforce does not document masking per field. Everything else in the Tooling tree is readable. Agentic Fabriq offers no action that WRITES to the Tooling API: deploying code is executing it later, on somebody else's trigger.

Read one topic's details. Read-only.

List the ids of records created or updated in a time window, with a cursor marking exactly how far the answer is guaranteed to cover. The incremental-sync primitive. It overlaps with a query on the last-modified date but is not the same call: this one is served from the platform's own change index and returns that cursor, which a hand-written date filter has no equivalent for — an agent that invents one will silently drop records written while the query was running. Salesforce limits the lookback to 30 days.

List the REST API versions this org supports. The call to make when everything else returns 'not found': Agentic Fabriq pins an API version deliberately behind the current release, and a sandbox upgraded on a different calendar from production can sit behind that pin. A sensible answer here alongside failures everywhere else identifies that situation, which is otherwise indistinguishable from a broken connection.

List the apps or tabs in one of the org's navigation menus. Read-only.

Return the org's approval processes and the approval requests awaiting the connected user. This is the action that produces the work item id the approve/reject/recall action needs — nothing else does, so without this that action would be one whose arguments no read can supply.

List the Lightning apps the connected user has access to. Nothing in this connector could name an app before: listing tabs returns the REST API's tab metadata and listing navigation items returns the CURRENT app's menu, and neither answers which applications this person actually has. It is also the only source of the app id the other actions in this family require.

List the members of one Chatter group. Read-only. Note that JOINING or adding somebody to a group is an access-control change and is not offered.

List the Chatter groups visible to the connected user, optionally filtered by a search term. Read-only.

List Chatter user profiles, optionally filtered by a search term. Read-only, and subject to the connected user's own visibility.

List the Salesforce CMS delivery channels the org publishes through. Read-only, and the action that produces the channel id the content listing needs.

List the published content in one Salesforce CMS delivery channel. Read-only. Publishing content is outward, one-way exposure to people outside the organisation and is not offered.

List the Experience Cloud sites — customer and partner communities — configured in the org. A READ of a surface whose writes are excluded: knowing a site exists and what it is called is what lets an agent explain where a record came from, while posting into one exposes content to people outside the organisation and is not offered.

Return the compact layout — the org's own answer to 'which few fields identify this record' — for several objects in one request. The best available default field set for a summary, and one call instead of one per object.

List the dashboards available to the connected user. Produces the dashboard id every other dashboard action needs.

List the data category groups that classify Knowledge articles and cases. Data categories are how an organisation files its Knowledge, so this is what turns 'find an article about billing' into a filter rather than a full-text guess. Read-only.

List the records, list views and reports the connected user has marked as favorites. Read-only, and a free source of the ids this person works with most.

List the people, groups and records a Salesforce Files document has been shared with. The audit read for the file family: an agent about to quote from a file, or an operator answering 'who can see this', had no way to ask.

List the invocable actions this org exposes — standard actions, custom Apex actions, autolaunched flows, email alerts and quick actions. THIS IS AN AUDIT READ AND IT LISTS THINGS AGENTIC FABRIQ WILL NOT RUN. Salesforce automatically publishes every invocable Apex method in an org at this surface, and it is reachable by anything holding the same API permission this connection uses — Agentic Fabriq's own action list is what declines to call it, not the permission you granted. Being able to SEE that list is what lets an administrator decide whether this connection should exist, so the list ships and the execution does not.

List the organisation's published Knowledge articles, optionally filtered by a search term. The read a support agent cannot work without: answering a customer from the org's own approved article is the difference between support and a language model improvising policy. Read-only, in the language you ask for.

List the saved list views defined on one object — 'My Open Cases', 'Q3 Pipeline'. These are the filters the humans in the org already use and already trust, so reaching them gives an agent the organisation's own definition of a segment instead of a filter it invented.

List one Experience Cloud site's managed topics — the navigation taxonomy customers see. Read-only; managing them is a configuration change and is not offered.

List the navigation menu items available to the connected user. Overlaps with listing tabs and is not the same answer: tabs are the REST API's metadata, this is what this person's navigation menu actually contains on a given screen size.

Return the organisation's own singular and plural labels for every object. More useful than it sounds in a renamed org: a customer who renamed 'Account' to 'Practice' has agents that keep saying 'account' to people who have not used that word in ten years. Read-only.

Return the display metadata for several objects in ONE request. An agent orienting itself in an unfamiliar org needs Account, Contact, Opportunity and Case at once; this is one call against the org's shared 24-hour allocation where the single-object form is four.

List the org's active workflow rules, for one object or for all of them. A diagnostic read: when a create or update through Agentic Fabriq produces an effect nobody asked for — an email sent, a field overwritten seconds later, an owner reassigned — an active workflow rule is usually why, and this is the call that names it. It is also the honest detail behind every write action's warning that Salesforce runs rules on insert and update.

List the quick actions defined on an object, or the org's global ones. READ ONLY: Agentic Fabriq deliberately offers no action that RUNS a quick action, because a quick action writes to an object named in the action's own definition rather than in the call — so the restrictions that stop a write reaching an identity or configuration object would not be able to see it. Listing them is how an administrator audits what exists.

List the records the connected user viewed most recently, across objects. A free source of record ids, and the call that resolves the most common under-specified request there is: 'update the account I was just looking at'.

List the queued and completed asynchronous runs of one report, with each one's status. Read-only.

List the connected user's report notification subscriptions. This is a READ of standing rules, not a way to create one — Agentic Fabriq deliberately offers no action that subscribes or unsubscribes, because a rule that acts on its own has no action row behind each of its consequences.

List the reports available to the connected user. Report ids are not guessable and no other action produces one, so this is required before a report can be run. Needs no add-on licence — the reports API is part of standard Salesforce functionality, not the separately-licensed analytics product.

List the REST resources Salesforce publishes at the pinned API version. This is the provider's own index of its API, so it is the honest answer to 'what does this connection's permission actually cover' — a larger question than 'what actions has this agent been granted', and one an administrator auditing the connection should be able to answer without taking Agentic Fabriq's word for it.

List the resources one Salesforce REST tree publishes at the pinned API version — Chatter, Support, Composite or Connect. The top-level index action returns the root; each of these trees publishes its own sub-index, and that sub-index is the cheap, ORG-SPECIFIC answer to 'does this org actually expose the thing I am about to call'. The composite entry is a DIRECTORY READ and not a composite call: it sends no body, and the tree it reads is chosen from a fixed list of four rather than from a path the caller supplies. Executing a composite, batch or graph request remains unavailable through Agentic Fabriq, because a subrequest names an arbitrary REST path and one granted action would re-expose the whole API inside a payload the allow-list never inspects. Reading that the org publishes those endpoints is how an operator confirms the gap is Agentic Fabriq's choice.

List every object this Salesforce org exposes, standard and custom, with each one's API name, label, key prefix and whether it is createable, updateable, deletable and queryable. Object API names are NOT guessable — custom objects end __c and may carry a managed-package namespace — so this is the discovery call to make first in an org you do not know.

List the tabs available to the connected user, grouped by app. Read-only navigation metadata.

List the object types Salesforce's Tooling API exposes in this org. Read-only reference metadata, and the action that tells you what the Tooling query and record actions can address.

List the org's Chatter topics, optionally filtered by a search term. Topics are how an org tags conversations, so they are a useful way into 'what has been said about renewals'. Read-only.

Search across objects by passing the term, the objects and the fields as separate parameters, instead of composing a SOSL statement as a string. The structured alternative to the text search action: same underlying search, but the grammar an agent most often gets wrong is assembled by Salesforce rather than by the agent. Both are available, because SOSL can express things the parameter form cannot.

DESTRUCTIVE — record a decision on an approval request: approve it, reject it, or recall a submission. The irreversibility is not data loss, it is process: a rejected request is CLOSED, and re-submitting creates a new request with a new history rather than restoring the old one. Approving also fires whatever final-approval actions the administrator configured — field updates, outbound messages, email alerts to people the agent never named. This addresses an approval WORK ITEM, not a record: use 'List approval requests' to get one.

Re-run every component of one dashboard against current data. It changes no record, so it is not marked destructive — but it is the most expensive read Agentic Fabriq offers for Salesforce: one call runs every query behind every component, and Salesforce caps how many dashboard refreshes an org may run at once, so an agent looping on this will fail for everyone in the org.

Run a dashboard with filters supplied for this run and return its results. A READ despite being sent as a POST: the filters travel in the body because there are several of them, nothing is saved, and the dashboard's own definition is untouched. The refresh action re-runs the dashboard as SAVED; this answers 'the same dashboard, but only EMEA'.

Run one saved list view and return its rows, with paging. Read-only, and bounded by the connected user's own permissions and sharing rules like every other read.

Run an EXISTING, administrator-authored report and return its results. Reports encapsulate the org's real definition of 'pipeline', 'at risk' or 'churn' — the groupings, the date logic, the exclusions somebody argued about — which an agent asked the same question in SOQL will otherwise reinvent and get subtly wrong. Constrained to EXECUTING a report by id: cloning a report and rewriting a saved report's definition are not available through Agentic Fabriq, because a rewritten report silently changes what every human in the org sees. Needs no add-on licence. A large report is one of the more expensive single calls an org can make.

Start a report running asynchronously and return the instance id to collect its results from later. This closes a hole rather than adding a family: the actions that LIST report instances and READ one have existed since the first Salesforce wave, and nothing in this catalog could CREATE an instance — so both could only ever read instances some other client had started. It is also the answer for a report large enough that the synchronous run times out. The saved report definition is not modified; per-run filter overrides apply to this run only and are not saved.

Run one SOQL SELECT against the connected Salesforce org. START HERE: Salesforce record ids are not guessable and every other action needs one, so a query like 'SELECT Id, Name FROM Account LIMIT 10' is the first call to make. SOQL is read-only by construction — the language has no INSERT, UPDATE or DELETE and Salesforce rejects statement chaining — and FOR UPDATE, UPDATE TRACKING and UPDATE VIEWSTAT are refused because they are the clauses that are not reads. Salesforce returns at most 2000 records per page; when 'done' is false, pass the returned 'nextRecordsUrl' back as next_records_url to get the next page.

Run one SOSL text search across several Salesforce objects at once. Use it when you know a name or a phrase but not which object holds it; use salesforce_soql_query when you know the object. Read-only — SOSL has no write form at all.

Submit one record into an approval process, optionally naming the process, a comment and the next approver. It changes no field, so it is not marked destructive — but it is outward-effecting: it puts an item in a real person's queue and Salesforce emails them. Its inverse is granted separately and ships alongside it: the approve/reject action's 'Removed' option recalls a submission, so this is not a one-way door.

Suggest Knowledge articles whose titles match a partial term, as the platform's own search box does. The cheap disambiguation read for Knowledge — the same shape as record suggestions, and the right first call before pulling a whole article body into an agent's context.

Run a READ-ONLY query against Salesforce's Tooling objects — Apex classes and triggers, flows, validation rules, layouts. Same restrictions as the ordinary query action: SELECT statements only, no statement separator, and the two query clauses that can take row locks are refused. THIS IS AN AUDIT READ. Listing an org's Apex is the only way to discover what its custom REST endpoints expose, and the only way to see what the invocable-actions list is actually offering. Agentic Fabriq will not run any of it. Reading the Tooling records whose configuration can contain stored credentials — named credentials, external data sources, connected applications, certificates, single sign-on configuration — is refused; everything else is readable.

DESTRUCTIVE — make the org's existing workflow rules evaluate against specific records, up to 100 at a time. It does not create a rule: an agent may use the account's rules and may never become one. But what the rules DO is decided by whoever wrote them — field updates that overwrite values with no undo, outbound messages, and email alerts to real recipients — and the caller cannot know in advance which applies. 'List workflow rules' exists so they can find out first.

Change one favorite's label or its position in the connected user's list. Personal navigation only; no business data is touched.

Change the connected user's own column widths, wrapping and left-to-right ordering for one list view. Personal display state only: the list view's DEFINITION — its filters and the query behind it — is not reachable from this action, and changing it for one person changes nothing for anyone else.

DESTRUCTIVE — overwrite named fields on one Salesforce record. Salesforce keeps no general undo: a field's previous value survives only if an administrator enabled field history tracking for that exact field beforehand, and that history is capped and read-only, so for most fields an overwrite is permanent. Only the named fields change; omitted fields are left alone. Salesforce uses the same permission for reading and rewriting, so granting this action separately is the only separation Agentic Fabriq can offer.

DESTRUCTIVE — overwrite fields on up to 200 Salesforce records in one call. The same absent undo as a single update, multiplied: this is the action to reach for after a SOQL query returns a list of ids, so one call can rewrite a hundred customer records. all_or_none defaults to TRUE, which rolls the whole batch back if any record fails; setting it false leaves a partial write that no single call can reverse. One object type per call.

Change the connected user's own display preferences for one related list — column widths, text wrapping, ordering, sort. NOT marked destructive, and that is a deliberate distinction rather than an oversight: what changes is one person's view of one related list, no record is touched, nobody else sees the change, and the inverse is this same action with the previous values — which the paired read returns, so the inverse is obtainable rather than merely conceivable.

DESTRUCTIVE — replace a SAVED, SHARED report's definition. No record is deleted, and the irreversibility is a different kind: the previous definition is not kept anywhere, there is no version history, and every person in the organisation who opens that report — plus every dashboard component built on it — now sees a different answer to the question they thought they were asking. The whole definition is replaced rather than merged, so send the current one from 'Describe a report' with your changes applied. This action requires an explicit confirmation argument in addition to being granted. Copying the report first is almost always the better move.

DESTRUCTIVE — create a record, or OVERWRITE the existing one, matched on a field marked External ID. The external-system-sync primitive: without it, 'create this contact if it does not exist' is a query, a branch and a write with a race in between that agents resolve by guessing. Because it can overwrite, the no-undo warning on updating a record applies unchanged — a previous field value survives only if an administrator enabled field history tracking for that exact field beforehand. Salesforce answers differently for a create and an update, so the caller can tell which happened.

DESTRUCTIVE — create or OVERWRITE up to 200 records in one call, matched on a field marked External ID. The batched sync primitive: one call reconciles a page of an external system into Salesforce. The same absent undo as a single upsert, multiplied by 200. The whole batch rolls back if any record fails unless that is explicitly disabled, and a partial write cannot be reversed by any single call.