← All topics

Work

How OrgBolt's AI turns a one-line request into a validated, deploy-ready Salesforce metadata package — without ever touching your org.

What Work does

Work is the first and heaviest phase of every task. Its job is to take a fuzzy human request ("add a priority field") and produce a ready-to-deploy Salesforce metadata package ("Priority__c picklist on Account, High / Medium / Low, FLS granted via a new permission set, flagged manual step for page layout"). Work reads, Work asks, Work generates. Work is strictly read-only against Salesforce — nothing lands in your org until you move to Deploy.

First-message orientation

On turn one, Work restates your task in its own words, lists every Salesforce org connected to this workspace, and names the one the change will target (your workspace's default org unless a task-level override is set). It then asks whether anything else needs to be known before generation starts — compliance constraints, deploy window, parallel changes in flight.

This single prompt replaces the old plan/build split. The model has the describe tools from turn one, so it can ground its proposal against the live org immediately instead of hand-waving until it's allowed to see the metadata.

Simplest solution first

Work is biased toward the lowest-complexity Salesforce answer. If a formula field solves the problem, Work proposes a formula field — even if you asked for a flow. If a validation rule solves it, Work proposes the validation rule before Apex. The rule of thumb: declarative beats programmatic, and Apex is a last resort.

When Work downgrades your request, it tells you why in plain English ("simpler, easier to maintain, runs less often") and offers three buttons: build it the simpler way, keep your original framing, or ask for more detail. You are always in the driver's seat.

Live org tools Work uses

Work has five read-only tools available from turn one. Each one costs a Salesforce API call against your daily limit but zero AI cost to you.

  • describe_object — reads real field API names and types before generating anything that touches that object. Runs automatically for objects mentioned in the task.
  • find_dependencies — before renaming, deleting, or retyping an existing field, Work looks up everything that depends on it (flows, validation rules, Apex classes, page layouts) so it can warn you about blast radius.
  • fetch_component — pulls the source of a dependent component (a flow body, a validation rule formula) when Work needs to update it in the same task.
  • list_objects — only when you explicitly ask a discovery question like "what objects do we use to track stages?". Work does not call this speculatively.
  • save_artifact — emits a named metadata file into the task's artifact tray. That tray is what Deploy picks up. No artifact = nothing to deploy.

Artifact blocks, not pasted XML

Every file Work produces goes through the save_artifact tool, not inline XML in chat. The artifact tray is how Deploy picks up the files, zips them into a Salesforce metadata package, and submits them to the Metadata API. If Work pastes XML inside a regular code fence, that's illustrative only — Deploy will not touch it.

Each artifact has a filename and a Salesforce metadata type. Work validates both. The most common failure mode in AI-generated metadata is source format vs Metadata API format — Work enforces Metadata API format (flat layout, fields inline inside the object file) because that is what the OrgBolt deploy pipeline accepts.

Customizing Work for your team

With the Custom Skills add-on, you can append workspace-specific instructions to Work in Settings → Task instructions. Common uses: naming conventions ("always prefix custom fields with Acme_"), compliance rules ("never propose a change to Financial_Data__c without mentioning SOX review"), or team defaults ("always mention our Slack #deploys channel when scheduling a production change").

These appended instructions run on every Work call the workspace makes. They do not bleed across workspaces, and they do not touch Deploy — each phase has its own customization slot.

Why Work is read-only

Splitting generation from deploy is the single most important safety property OrgBolt has. You get to read the exact metadata that will land in your org. You get to ask Work to change it. You can leave the task, come back tomorrow, and deploy it then. Nothing happens to your Salesforce org until you click Deploy.

If a Work artifact looks wrong — wrong field name, wrong type, missing permission — say so in chat. Work will regenerate. You can iterate on Work as many times as you like without spending a single Salesforce API call toward a deploy.