Access Rules

Access Rules control what the Cirra AI MCP server may read and write in your connected Salesforce organizations. They let you tighten access far beyond the broad data categories — down to a single object or field, and scoped to a particular environment type, connection, role, or individual user.

These permissions apply on top of (not instead of) the permissions configured in Salesforce. The Cirra AI MCP server can only ever do something if both Salesforce and your Access Rules allow it — and when several rules apply, the strictest one always wins.

You manage them on the Access Rules page in the MCP Server settings.

What a rule is made of

Every rule answers four questions:

• Where it applies — an environment type (Production, Sandbox, Developer, Scratch, or All environments) and, optionally, one specific connection (a single connected org). Leave the connection unset and the rule covers every org of that environment type.
• Who it applies to — a role (for example Everyone, Admin, or Member) and, optionally, one specific user. The role and user axes appear only for Team accounts; a personal account has no roles or other users, so those columns are hidden.
• What it targets — one of:
  • a whole data category: Metadata, User data, Personal setup data, or Business data;
  • a specific object (for example Account);
  • a specific field (for example Account.AnnualRevenue).
• Access level — No access, Read only, or Read & write.

The rules table

Each rule is a row, with these columns:

• Specificity — how narrowly the rule is scoped (see Precedence below). The table sorts by specificity by default, broadest first.
• Where — the environment type or the specific connection.
• Applies to — the role and/or user (Team accounts only).
• Target — the data category, object, or field, with a small badge (object, field, or mixed when a rule covers more than one).
• Access — the level granted, shown as Read only, Read & write, or No access.
• A lock icon shows whether more specific rules may relax this one (see below). A Capped badge means a broader locked rule is holding this rule down, so it is not granting everything it otherwise would.

Use the Environment type, Connection, Role, User, and Data category filters, or the Search box (which matches connection names and object/field names), to narrow a long list. Select one or more rows to edit or delete them in bulk.

If no rule matches a given object or field, its access simply follows the broader category (and, ultimately, Salesforce) — there is no implicit denial.

How rules combine (precedence)

The guiding principle is simple: the strictest applicable rule always wins.

By default every rule acts as a ceiling — nothing more specific may exceed it. So a broad "Business data — Read only" rule caps a narrower "Account — Read & write" rule down to Read only.

When you do want a narrower rule to grant more than a broader one, turn on More specific rules can relax this on the broader rule. With that enabled, a more specific rule (higher specificity) may widen access above the broader rule's level. The lock icon in the table shows, at a glance, which rules can be relaxed and which cannot. A rule that would grant more but is held down by a broader locked rule is marked Capped.

Specificity, from broadest to narrowest, increases as a rule targets:

• a narrower scope — All environments → an environment type → a single connection;
• a narrower audience — Everyone → a role → a specific user;
• a narrower target — a data category → an object → a field.

Because everything is layered on top of Salesforce, the access the server actually gets for any object or field is the most restrictive of: what the connected Salesforce user may do, and every Access Rule that applies.

Creating a rule

Click Add rule and fill in the dialog:

1. Role and User — who the rule applies to (Team accounts only).
2. Environment type and Connection — where it applies.
3. Restrict — choose whether the rule targets a data category or objects and fields. For objects and fields, add one or more objects, and expand an object to limit specific fields instead of the whole object.
4. Data category — shown when you are restricting a category.
5. Access level — No access, Read only, or Read & write.
6. More specific rules can relax this — leave off to make the rule a hard ceiling; turn on to let narrower rules grant more. This toggle is locked in cases where relaxing would not make sense.

Edit or remove an existing rule from the Actions column of the table.

Previewing effective access

Rules interact, so the page includes an Effective access panel that shows exactly what the Cirra AI MCP server can do after every applicable rule is merged — no need to work it out by hand.

Pick a Connection (its environment type is filled in for you) and, optionally, a User (its role is derived) to see the resulting access for each of the four data categories. Add an Object — and optionally a Field — to resolve access all the way down to that specific target.

Leave the User or Connection blank to see the access that applies when no special rule exists for that person or org. Use the refresh control to re-run the preview after changing rules.

In the example above, a broad Business data — Read only rule and a narrower Account.AnnualRevenue — No access rule combine so that the member can read Account in general but not its Annual Revenue field — the stricter field rule wins.