You need one thing: a sandbox or a free Developer Edition org. Production is never a workspace - see the safety model below.

• Connect from the Connect page: you sign in on Salesforce's own login page (OAuth) - OrgTide never sees your password, and stored credentials are encrypted at rest. Pick the sandbox option to sign in through test.salesforce.com.
• Switch or add orgs from the org badge (top right). Your plan sets how many workspaces you can connect - Free 1, Pro 3, Developer 10. Downgrading never deletes an org: extras lock (🔒 in the switcher) and unlock the moment you upgrade again.
• One org at a time, in every tab. Switching org switches it for all your open tabs. A tab still showing the old org says so and does nothing until you reload it (or switch back), so it can never act on an org it isn't showing.
• Idle connections expire. An org untouched for about 30 days has its stored credentials destroyed automatically - just reconnect; your changes, releases, and history are unaffected.
• A good first session: connect → teach the AI your org (one click on Home) → build something small in Work → press Deploy on its card → see it confirmed, then find it under Changes. The checklist on Home walks you through these four steps.

Everything in OrgTide moves through the same path, and nothing skips a step:

• Say what you need in Work - a question, a review, a build, an access change. Type it, or paste a screenshot of the thing you mean.
• Read the card. A build arrives as a plain-English description of what would be created, who can see it, where the fields go, and what the safety scan found. Nothing has touched your org yet. Correct it with a follow-up message.
• Approve once. Deploy to <your sandbox> on the card is the one click that writes: a rollback snapshot is taken first, the change's own Apex tests run inside one all-or-nothing deploy, and a receipt reads the org back to confirm what landed. Save for later keeps it in OrgTide instead.
• See it in Changes. Changes lists what is waiting to go in and every deploy with its result - deploy, check, edit, roll back from there.
• Bundle into a release on Releases when the work spans several changes - generate release notes and an impact report, then promote the release to another sandbox or, through typed confirmations, to production.

Quick one-off change? One conversation and one click is enough. Releases and promotion earn their keep when you are shipping a body of work between orgs.

Press ⌘K (or the Search button in the top bar) anywhere in the app: jump to a page, a change, or a release, or run actions directly - New build, Scan for drift, Export org metadata, Refresh org profile.

• Metadata only, never records. OrgTide reads code, flows, objects, and permissions - never Accounts, Contacts, or any business data.
• Nothing writes without your click. Every change is a card or a diff you read first; the deploy is one explicit click on that card or on its row in Changes.
• Gates on every deploy: the change's Apex tests run inside the deploy (a failing test stops it and nothing is saved). A scan for risky patterns (callouts, email sends, dynamic SOQL, without sharing, named credentials) is shown in full before you click; when it finds something you tick "deploy anyway" (on a Work card, the Deploy click itself accepts what the card shows), and OrgTide's server checks that tick. A 75% coverage gate applies to every check, release deploy and promotion - only a one-click sandbox deploy can land with less, marked "coverage too low for production". A promotion to production that makes a field required also runs production's own Apex tests, so a test that saves a record without that field stops the deploy.
• Flows never activate themselves. A deployed flow always lands as a new inactive version - you activate it in Salesforce when ready.
• Production is a deploy target, never a workspace. OrgTide can't browse production; it deploys there only through the release-promotion path with typed confirmations, and reads from it only to verify identity, snapshot for rollback, run drift scans you request, and - when a release you promote changes existing fields - check that production's copy of those fields is still the one the change was made from (if not, nothing is sent).
• Undo exists. Every deploy takes a rollback snapshot first; Roll back is on the Work card and under Changes → History. Deploys made before OrgTide checked your org for rollbacks (23 September 2026) can't be rolled back here - undo those by hand.
• Your data. What OrgTide stores, what it sends to the AI, who processes it, and what deleting your account removes are on the Privacy page.

Work is where you talk to OrgTide about your org. Each conversation is saved per org (rename it from its title; the list keeps your 200 most recent). Type a request, paste a screenshot (an error, a page, an ERD), or attach a component's real source with + From your org. Attachments are reference material, never instructions.

Questions. Formulas, validation rules, how-tos, best practices. When current information matters (recent releases, limits, new features), Work searches the web and cites its sources under the answer - searched questions draw a little more of your allowance. Work can also read lists from your org on request ("all custom objects", "the fields on Invoice", "where is the Tier field used?") and shows them as a card you can filter and copy - never retyped from memory. When an answer is wrong or outdated for your setup, save the correct fact under Saved corrections on Account (the link is at the foot of the thread list) - every answer reads them first, in every org.

Reviews. Review on Browse (Apex classes, triggers, LWC and flows) opens a conversation with the component attached and a review request ready to send: findings ranked High / Medium / Low, a security note, next steps. Fix these turns the ticked findings into a corrected version, with the class's existing test brought along.

Builds. Ask for anything deployable - an object with fields and rules, a trigger with its tests, a flow (always inactive), an LWC, a field on Account. Work first describes what it would build in one or two sentences; Build this makes it. The card then shows:

• a plain-English description of every part and the safety scan;
• for code (Apex, triggers, LWC, flows) the compile check: your org's own compiler checks it before you see the card - nothing is saved - and OrgTide corrects what it finds once; anything still wrong is listed on the card, and Deploy waits until it is fixed (describe the correction in a follow-up message);
• for Apex, the tests run in your org as well (check-only - nothing is saved): the card says whether they pass and shows the real coverage of each class. A failing test, or a class under 75%, gets one automatic fix of the tests the build wrote (tests already in your org are sent as they are); a class still under 75% can be deployed to your sandbox, marked "coverage too low for production";
• Used elsewhere in your org - the Apex classes, triggers and LWCs in your org that use the build's code (read from your org, no AI). Update all N in this change (or Update it in this change) updates them on the same card in one AI request - each with the reason, their tests come along, and the compile check and tests run again - so everything deploys together. Flows, pages and other components that use it are named to check by hand;
• Who can see it - the System Administrator profile is ticked from the start; add profiles or a permission set with change (a permission set is created, never assigned);
• Page layouts - which layouts of an existing object show the new fields, in a section called "New Fields" or the name you asked for ("in a new Pricing section" - existing fields you name are moved into it). A layout that already has a section by that name gets the fields added to it - never a second one; an object with one layout has it chosen for you;
• Record pages, report types (optional, an existing object gaining fields) - Dynamic Forms record pages get the new fields at the end of their first field section (move them in Lightning App Builder); a record page without Dynamic Forms shows the page layout's fields, so the Page layouts choice covers it. Custom report types based on the object get them as columns, not ticked by default. One the fields can't be added to is named on the card with the reason;
• Tab for a new object - its icon, whether it shows in the navigation, and which apps it is added to; the object's settings (record name or auto-number format, reports, search, history, activities, Chatter, sharing) in one sentence - change sets them right on the card, no AI and no message needed.

Deploy to <your sandbox> is the one approval: snapshot first, the build's tests inside, then a green receipt that confirms what landed - fields, access, layouts. Each class that is still short for production is listed right under the result with its own button - Write a test (or Raise the coverage) opens a new conversation with a card that holds only the test; the class itself is never changed. Save for later keeps the build as a change under Changes instead. A follow-up message ("make Amount required", "use a picklist instead") produces a changed version of the same card; a failed deploy offers Fix with Claude, which sends the errors back and builds the corrected version.

Changes to existing fields. "Make the Tier field required", "add Gold and Platinum to Priority", "set Region's help text": Work changes a custom field that already exists - its label, help text, description, required on or off, new picklist values (added to every record type that uses the picklist too), a longer text length, or its default value. The change starts from the field's current definition, read from your org, so nothing you did not ask for moves, and the card shows what changes, before → after. Work never builds a change that could lose data - a new type, removing or renaming picklist values, a shorter length - and says so plainly: those are made in Setup. Standard fields are changed in Setup too, and an installed package's fields only by that package. If the field is edited in Setup after the card was made, Deploy refuses and asks you to build it again. Making a field required puts an amber warning on the card: from then on every save needs it - by people, flows, Apex, integrations and data loads - and records where it is blank fail their next save until it is filled in.

Access changes. "Give the Standard User profile edit on the Tier field", "remove delete on Invoice from Marketing": Work reads today's access from the org and shows a before → after card (reductions are flagged in amber first) that deploys the same way. Unnamed access defaults to read, create and edit - never delete, never view-all.

What it can generate: objects with every field type (roll-up summaries on master-detail, rich text, auto number, time, geolocation, compound Address - the last needs "Use custom address fields" enabled once in Setup), record types, list views with their filters, global value sets, custom metadata types with their config records, custom settings, queues and public groups (members are added in Setup), custom labels, platform events, Paths with per-stage guidance, Apex (always with a test class), triggers, LWC, and flows. Builds are grounded in your org: its org brief, and the definitions of the objects you name, read first (fields, picklist values, required fields - never records); the org's own compiler checks the code before you see the card, and Salesforce checks everything again when you deploy.

Changes is one list of everything you changed in the active org. To deploy holds what is built but not in the org (or no longer - edited since, failed, rolled back); History holds every deploy attempt with its result. A change built in Work links back to the conversation that made it.

A change that is waiting opens to its parts and these actions:

• Deploy to <your sandbox> - the same one-click deploy as the card: the safety scan runs first, and when it finds nothing the deploy starts - a snapshot is taken, the change's tests run inside the deploy, the row shows progress and finally the receipt. When the scan finds something, the findings are listed with a "deploy anyway" tick before anything is sent. Unsaved edits in Files must be saved first - Deploy uses the saved files. Reloading the page mid-deploy is fine - the row keeps watching.
• Check without deploying - a check-only run (nothing written) with the full report: errors, failing tests, coverage against the 75% gate, risk findings - then Deploy now to <your sandbox> from a passed check (tick the findings first when there are any). A release always goes this way: its row has one Check before deploying button, and Deploy now after a passed check is the only click that writes.
• Files - preview every file and edit it in place; edited files still go through the tests and the scan.
• Fix it in the conversation (a change from Work) or Fix the errors with Claude (an imported change): the errors go back and a corrected version comes out.
• Add to a release, Download .zip (a standard Metadata API package - deploy it anywhere with the sf CLI or Workbench), Delete (removes the saved change only; nothing in your org changes).

What you approve is exactly what deploys: OrgTide keeps the precise files it checked, scanned or showed you, and if a change is edited in between (in Files, or by a newer build of the same components), the deploy stops and asks you to look or check again - nothing is sent.

Import metadata (above the list) works the other way: upload a metadata zip (Metadata API or SFDX source format, up to 10MB) or individual files - Apex, triggers, flows, objects, permission sets, LWC bundles - and everything lands verbatim as one change. No AI call, no allowance cost, with two guardrails: flows always arrive inactive, and anything unsupported is listed as skipped, never silently dropped.

History shows each deploy as In your org, In your org - coverage too low for production (the tests passed but cover too little; production will refuse it until the tests cover more), Failed - nothing was changed, or Rolled back, with the receipt and Roll back (components the deploy created are deleted and ones it changed go back to how they were; Salesforce checks the whole rollback first, and if anything would stop it nothing is changed. The confirmation lists exactly what goes and what stays as deployed. Rollbacks go newest first - a deploy whose components a newer deploy changed waits until that one is rolled back). Changes are per org: switch orgs (top right) to see that org's list.

Browse is a read-only, filterable list of everything in your connected org - custom objects, fields (per object, standard and custom), Apex classes, triggers, LWCs, flows, and permission sets.

• Click the name of an Apex class, trigger, LWC or flow to read its current source from your org. A flow opens on its diagram (Diagram / XML, and whether it is the active version); an LWC has a tab per file. Copy takes the file on screen; Download saves it as Salesforce keeps it (an LWC as a zip with its lwc/ folder). No AI, nothing changes in your org.
• Ask / Review on an Apex class, trigger, LWC or flow opens a Work conversation with its real source attached - a question answered from your actual code, or a review with ranked findings.
• History on an Apex class, trigger, LWC or flow that OrgTide has deployed over lists the earlier versions it saved just before each of its deploys that included it (up to 20). Restore makes one a change on Changes that you check and deploy like any other - nothing is sent to your org from Browse, and a restored flow arrives as a new inactive version.
• Copy the list: every view has Copy list (plain text) and Copy as table (Markdown - pastes as a real table into Confluence, Notion, or GitHub). Both copy exactly what's shown, so filter first to copy just what you need.
• Objects → fields: click any object to open its full field table (API name, type, label).
• It costs no AI usage - these are direct metadata reads, so browse freely even when your allowance is spent. Metadata names only; OrgTide never reads your records.
• To bring a component into a deployable bundle, use Add from org on a release.

One click on Home teaches the AI your org: OrgTide reads the org's metadata inventory (names and shapes only - never records) and writes a compact brief of what the org does, its naming conventions, key objects, and automation patterns. Every answer and every build in Work then FITS your org - reusing existing objects and value sets instead of duplicating them, matching your naming. Uses one generation; refresh after big schema changes (once per hour).

One button reviews your org's largest Apex classes plus the flow inventory into a 0-100 score with ranked findings (each run costs one generation). The header sparkline tracks the score across runs, so you can see the org improving as you fix things. Any finding's component can be reviewed in depth from Browse → Review.

A release is a named bundle of changes (plus components pulled straight from the org via Add from org - Apex, triggers, LWC, flows, permission sets, custom objects, even individual custom fields - including changes made outside OrgTide). From the release you can:

• Generate release notes + a risk score, and an impact report that scans org dependencies for blast radius.
• Deploy to this sandbox - it opens on Changes, where it is checked first (tests, coverage, safety scan) and then deployed on behalf of the release.
• Promote it to another connected sandbox - OrgTide previews what differs in the target, then runs a check-only validation there (tests, the 75% coverage gate, the risk scan) before you promote. Promoting to production is three explicit steps: (1) a check-only validation runs the full gates against production without writing anything, (2) you review the risk findings (tick to proceed when there are any) and type promote to production, (3) the deploy lands atomically, with a rollback snapshot taken first. A release that changes existing fields goes to another org - a sandbox or production - only while that org's copy of each field is still the one the change was made from; if it has its own version, nothing is sent - make that change in that org's Setup, or take it out of the release.
• Download .zip (manual deploy) to hand off outside OrgTide, or Save as reusable package (see Packages).

A package freezes a release's artifacts into an account-level bundle that follows you, not one org. Import it into any connected org and the artifacts arrive as changes there - reviewed and deployed through the normal pipeline. Built for "I solved this in client A's org and want it in client B's."

The board groups your orgs into families - sandboxes with their production org as a strip beneath them - showing each org's latest deploys, releases, and incoming promotions. Production connections are deploy targets only and never appear in the org switcher.

Drift check compares your active sandbox against its production - or a sibling sandbox in the same family: components that exist in only one org, plus ones whose size or status differs - the "someone edited prod directly" signal. It appears on a family's card when your active org is one of that family's sandboxes and there is something to compare it with - the family's production org (connected as a deploy target) or another sandbox. Apex, triggers, LWC and flows can show an exact side-by-side source diff. Scans run only when you click, read metadata only, and are free (no AI call).

Export org metadata (button at the top) downloads the active org's own work - Apex, flows, objects, config - as a standard metadata zip: a point-in-time backup you own. Pure metadata read, free (no AI call), once per 15 minutes per org.

Choose the model in Work's message box - it is used for your next message and for the build that follows it, and it is remembered as your default (also on Account).

• Sonnet 5.5 (the default) - fast and strong; the right choice for nearly everything.
• Opus 5.5 - the most capable, for gnarly builds and deep reviews; draws about twice the allowance. Included in paid plans - on Free, Opus shows as locked in the picker, and a saved Opus default runs Sonnet 5.5 instead (Account says so).

OrgTide sets how hard the model thinks for each kind of work - quick for conversation, more for builds - so there is nothing to tune.

Every AI action (a question, a review, a build, a health run, release notes…) counts against a fair-use allowance shown as percent bars per rolling window (daily and monthly). The allowance is shared across all your connected orgs and weighted by how heavy each generation actually was - one big Opus build draws more than a quick question. When a window fills, the bar tells you when budget frees up.

On paid plans, Continue today lifts the daily pace limit for 24 hours - usage then draws from your monthly allowance instead. The button is on the usage banner, the Usage page (when today's bar is full), Account, and the limit notice on pages such as Org Health and Releases; in Work, the notice points you to Account. Plans (org count, Opus access, allowance size) are managed on Account.

Where did Ask, Build, Analyze, Permissions, Drafts and Deploy go?

Into two places. Work is one conversation where you ask, build, change access and get reviews - Analyze's address opens Browse, where Review starts a Work conversation. Changes is Drafts and Deploy in one list. The other old addresses take you to Work or Changes.

Why didn't my flow activate after deploying?

By design - flows always deploy as a new inactive version. Activate it in Salesforce Setup once you've verified it (safety model, above).

Can OrgTide see my records?

No. OrgTide reads metadata plus a few setup records a task needs - such as your org's name and type, your own user's permissions, and the permissions of the profiles and permission sets you ask it to change (Privacy lists them). Business records - Accounts, Contacts, Opportunities - are never queried or stored, and never reach the AI unless you paste or attach them yourself.

My org session expired - what do I do?

Reconnect from the org switcher (top right) or the Connect page. Your changes, releases, and history are unaffected.

A deploy failed - is my org broken?

No. Deploys are all-or-nothing: on failure nothing was applied. The card lists the exact errors and offers Fix with Claude; a failed row under Changes → History offers Fix it in the conversation. Either sends the errors back and builds the corrected version, then you deploy again.

The deploy said "coverage too low for production" - what does that mean?

The tests passed but cover too little of the Apex. A one-click sandbox deploy still lands, marked that way; a check, a release deploy or a promotion needs 75%, and production refuses it until the tests cover more. Click the button next to the class - Write a test (or Raise the coverage under the deploy result on the Work card), or Write a test on its History row - to write or strengthen its test in a new conversation; the class itself is not changed.

What's the difference between a release and a package?

A release lives in one org and is for shipping a body of work (notes, impact, promotion). A package is an account-level frozen copy for reusing that work in other orgs.

How do plans and billing work?

Free includes one workspace (a sandbox or a free Developer Edition org) and the base allowance. Paid plans add more workspaces, production deploy targets, Opus access, and bigger allowances. Upgrade, switch plans, or cancel any time from Account - checkout and card details are handled by Stripe; OrgTide never sees your payment information. Downgrading never deletes anything: orgs beyond the smaller plan's limit are locked (visible in the switcher with a 🔒) and unlock instantly when you upgrade again.

Can I bring metadata from another org, or from a repo?

Two paths. Import metadata (on Changes) takes a metadata zip or individual files and lands them verbatim as one change - no AI involved, flows arrive inactive - ready to check and deploy. Add from org (on a release) pulls components straight from any org you've connected. Use Import for old orgs, repos, and hand-offs; Add from org for things already deployed somewhere you can reach.

Can I take my data with me - or delete it?

Yes to both. Export the active org's metadata as a zip (Environments), download any change or release as a standard Metadata API package, and delete your account from Account - deletion cancels any subscription and permanently removes your orgs, conversations, changes, and history. Privacy lists the few things that remain: Stripe's invoices, a log of admin actions on your account, and backups that expire within 7 days.

Something else?

Open a case on Support - replies come back right on that page (the Support link in the sidebar shows a badge when there's an answer waiting), and you can keep the conversation going until it's resolved.