Frequently asked questions

No. Deploy always asks. For production orgs, Deploy defaults to Validate-first (a checkOnly run that changes nothing) and you click again to deploy for real. Work never touches your org at all — it reads describe metadata but cannot write.

Salesforce deploys are transactional at the metadata API level. If any file in the zip fails to deploy, the whole package is rolled back and no changes are committed. OrgBolt surfaces the Salesforce error text in chat with the offending file, and you go back to Work to fix it. Nothing in your org is in a half-applied state.

Salesforce does not have a built-in undo. What OrgBolt gives you is the metadata that was deployed — saved in the task — so you can reverse it by hand if needed. For flows specifically, OrgBolt always deploys as Draft, so the old version keeps running until you manually activate the new one. A dedicated undo/rollback flow is on the roadmap.

Work is biased toward the simplest Salesforce answer that solves the requirement. If a validation rule covers what you asked for, Work proposes the validation rule first — it's simpler, runs less often, and is easier to debug. Work always offers a "no, I really want a flow" button if you have a good reason.

Salesforce field-level security is opt-in per profile. A newly deployed custom field is invisible to everyone except System Administrators unless something grants the field to them. Work will flag this and offer to generate a permission set in the same task so the field is actually visible to the users you care about.

Yes. Work has a fetch_component tool that pulls the source of existing Salesforce components when it needs to update them — for example, to modify a flow that depends on a field you're renaming. These reads count against your Salesforce daily API limit but cost nothing toward OrgBolt AI usage.

Settings → Workspace → disconnect next to the org. OrgBolt revokes the OAuth token via Salesforce, deletes the token from the database, and drops the row. You can also revoke from Salesforce Setup → Connected Apps OAuth Usage at any time; OrgBolt will handle the expired token cleanly next time it tries to use it.

Yes, and most teams do. A typical setup is one workspace with three orgs: Dev, UAT, and Production. Each task can be assigned to one or more orgs, and Deploy offers a button per assigned org.

Whatever version your org actually supports. OrgBolt probes the highest available API version during OAuth and stores it per-org. The package.xml version and REST URLs are generated from that stored value, so a newer org gets newer features automatically.

In OrgBolt's Supabase Postgres database, scoped by workspace via row-level security. Tasks and chat messages are retained for the life of your account and deleted 30 days after you request account deletion. Audit logs are kept 7 years but anonymized (user_id nulled) after deletion, for compliance reasons.

No. OrgBolt's AI calls go to Anthropic's Claude API on the paid API plan, which does not store or train on your data. OrgBolt itself stores your chat transcripts and task descriptions so you can read them later, but they're never used to train any model.

Yes. Settings → Data Export produces a JSON file with your tasks, chat history, deploy records, and workspace settings. GDPR Article 20 (right to portability) applies — we make the export available whether or not you're in the EU.