SBCF is built on Salesforce Platform capabilities and should use the Salesforce security model as the source of truth. The framework does not replace Salesforce authentication, authorization, sharing, or audit controls.

The MCP Server and external clients should authenticate to Salesforce through approved OAuth flows and Connected Apps.

Recommended practices:

• Use a dedicated Salesforce integration user.
• Use OAuth instead of static passwords.
• Rotate credentials according to organizational policy.
• Restrict Connected App policies to approved users and profiles.
• Avoid storing long-lived access tokens in source control or local scripts.

Authorization should be enforced through Salesforce users, profiles, permission sets, and permission set groups.

Each Business Capability should document the permissions it requires in SBCF_CapabilityMetadata.requiredPermissions.

Production implementations should explicitly review object-level CRUD and field-level security for every field accepted or returned by a capability.

For each Business Capability, confirm:

• Required objects are readable or creatable as needed.
• Sensitive fields are not exposed unnecessarily.
• Response DTOs do not leak fields outside the caller's intended access.
• Future schema generation respects CRUD/FLS.

Apex class sharing declarations affect record visibility. Validate whether a capability should run with user sharing, inherited sharing, or controlled system behavior.

The current framework should be reviewed capability by capability before production use in regulated environments.

Capabilities that write records should define transaction boundaries clearly:

• Which records are created or updated.
• Which failures return validation responses.
• Which failures should throw exceptions.
• Whether partial success is allowed.

Orchestrated capabilities should use savepoints when all-or-nothing behavior is required. Customer onboarding currently uses this pattern to roll back related record creation if a downstream operation fails.

Use .env.example only to document required variable names. Never commit real secrets.

Recommended production options:

• Cloud secret manager
• CI/CD encrypted variables
• Salesforce Named Credentials where applicable
• Runtime environment injection

Use Salesforce audit capabilities and platform logs to track:

• API logins
• Integration user activity
• Record creation and updates
• Failed requests
• Permission failures

MCP Server logs should avoid access tokens, PII, and sensitive Salesforce field values.

The integration user should have only the access required by enabled capabilities.

Example:

• Customer Lookup: read Account, Contact, Case, and Opportunity records.
• Account Creation: read and create Account records.
• Case Creation: read Account records and create Case records.
• Customer Onboarding: read Account records and create Account, Contact, Opportunity, and Task records.