Salesforce Enterprise Security and Procurement Guide

Use this guide when preparing a Salesforce-backed BuoyForms rollout for enterprise review, security review, or AppExchange planning. It complements the Salesforce setup guide by documenting operational posture rather than step-by-step mapping.

Connected App Posture

Create one Salesforce Connected App per environment. Use separate callback URLs for production, staging, and sandbox validation so test authorizations never share credentials with production.

Recommended OAuth settings:

• Enable OAuth web server flow.
• Require the api scope for object metadata and record create/upsert.
• Require refresh_token or offline_access only when background submission sync is enabled.
• Avoid broad identity, full, chatter, or admin scopes unless a customer-specific implementation explicitly requires them.
• Rotate the client secret after failed pilots, vendor transitions, or suspected exposure.

Least-Privilege Scope Review

Before launch expansion, confirm that the customer’s Salesforce admin has reviewed which objects can be written by the integration user. BuoyForms should be mapped only to the objects needed for the migration or form workflow, usually Lead, Contact, Case, or a named custom object.

Minimum evidence for the procurement packet:

• Connected App client ID and callback URL by environment.
• OAuth scopes used and why each is needed.
• Integration user profile or permission set name.
• Target objects and mapped fields.
• Required-field validation result from object metadata.
• Sandbox test record link or record ID.

AppExchange Readiness Checklist

BuoyForms is not AppExchange-listed until packaging and Salesforce security review are complete. Use this checklist to prepare that track without overstating current availability.

• Package strategy selected: managed package, unmanaged metadata helper, or connected-app-only deployment.
• OAuth scopes reviewed for least privilege.
• Connected App setup screenshots captured.
• Security review materials collected for data flow, token storage, logging, and incident response.
• Sandbox create/upsert tests pass with logs.
• Retry and idempotency behavior documented for duplicate-prevention review.
• Customer-facing setup guide and troubleshooting guide are linked from the implementation packet.

Health Center Evidence

The Salesforce Health Center should be reviewed before customer signoff. Capture the following fields in the handoff packet or implementation notes:

• Connection status and token health.
• Last successful sync and last failure.
• Mapped object count, mapped form count, and mapped field count.
• Recent sync logs and retry queue status.
• Admin alerts for repeated sync failures, token attention, or failed retry queue items.

Repeated Salesforce failures should block migration signoff until a sandbox test passes or the customer accepts the limitation in writing.

Incident and Rollback Notes

If Salesforce sync fails after launch, pause the affected mapping before publishing additional migrated forms. Preserve integration logs, failed side-effect tasks, Salesforce API responses, and customer-visible submission IDs. Re-enable only after a small replay or test mapping succeeds.

Rollback evidence should include:

• Form ID and mapping config ID.
• Salesforce org ID and environment type.
• Failed submission IDs.
• Error messages and status codes.
• Retry count and next retry time.
• Customer communication timestamp.

Procurement FAQ

Does BuoyForms require a Salesforce managed package? Not for the current integration path. The primary integration uses OAuth, object metadata, field mappings, and record create/upsert. A managed package can be evaluated for future enterprise packaging.

Can BuoyForms test in a sandbox before production? Yes. Connect a sandbox org, map the form, run Test Mapping, submit a real draft form response, and verify the created or upserted Salesforce record.

Can historical GetFeedback responses be inserted into Salesforce automatically? Do not assume automatic insertion. Preserve historical exports during migration and use the guarded historical import workflow only when the customer approves mapping, dry-run results, and duplicate policy.

What blocks launch expansion? Do not expand Salesforce-native claims until sandbox create/upsert, logs, retry status, and mapping validation pass for the customer workflow.