Salesforce Policy Guardrails

Salesforce Integration Policy Guardrails

Overview

Turn recurring integration hazards into deterministic checks with fail-closed severity, exact evidence, owned exceptions, and no secret-dependent fork execution.

Prerequisites

• Repository, Salesforce DX or adapter layout, languages, CI trust model, protected branches, and code owners
• Current API EOL, OAuth, security, object and field access, sharing, limits, and deployment contracts
• Policy authority, severity model, baseline findings, exception format, expiry, and remediation owners

Tool Discipline

Use Read, Glob, and Grep to inspect approved repository and evidence files, WebFetch to re-check current first-party Salesforce documentation, and Write or Edit only for secretless plans, fixtures, configuration, and redacted receipts.

Current Contract

Salesforce requires parameter-safe query construction and layered authorization, while supported API versions and client-app guidance evolve. Static rules cannot prove runtime CRUD, field access, sharing, limits, or org identity and must be paired with protected tests.

Authentication

Static and fixture gates must run without Salesforce credentials. Protected runtime checks use a minimum non-production principal only after exact-head trust and must never expose secrets to fork code.

Instructions

1. Inventory query construction, credentials, app and OAuth settings, API versions, objects and fields, mutations, events, retries, logs, and deployment paths.
2. Define checks for string-built SOQL, secrets, unsafe logs, retired or fixed versions, broad scopes, wrong-org defaults, and unrestricted queries.
3. Add rules for missing CRUD and field-access evidence, destructive operations, blind retries, unbounded concurrency, checkpoint resets, and reconciliation gaps.
4. Create positive and negative fixtures for every rule and pin scanners, actions, runtimes, dependencies, and rule hashes.
5. Run secretless checks on every change and protected org contract checks only in trusted environments.
6. Ratchet against a reviewed baseline; require exact finding, owner, reason, scope, expiry, and compensating control for exceptions.
7. Measure escapes and false positives, close expired waivers, and update policies from incidents and Salesforce contract changes.

Approval Boundaries

Do not suppress blockers, broaden globs, add permanent waivers, expose CI secrets, or auto-fix Salesforce org state without policy-owner approval.

Output

Return the policy catalog, authority and hashes, fixture results, findings, baseline delta, exceptions with expiry, protected-test receipt, and owners.

Error Handling

Example

A redacted completion receipt might look like this:

profile=enterprise; rules=12; fixtures=24-pass; blockers=0; waivers=2-expiring; fork-secrets=0; runtime=protected-pass

Resources

• Salesforce SOQL injection guidance
• REST API end-of-life policy

Next Steps

Run the workflow first in the lowest-risk authorized org and preserve its redacted receipt. Schedule a review against the next Salesforce seasonal release and the customer change calendar.