Org Documentation

Any task conversation can produce documentation. Ask for it in plain language — "document the Account object", "give me an overview of this org's automation", "explain the relationships between Leads and Opportunities" — and the AI researches your org's actual metadata, then writes a structured markdown document: a purpose summary, field and automation tables, short code excerpts where they clarify something, and relationship or flow diagrams.

The document is saved to the task and opens automatically in the document viewer the moment it's ready. From there you can read it, download it as a .md file, copy the raw markdown, or discard it if it missed the mark.

1. Open any task (or create one) with a connected org.
2. Ask for documentation in your own words. Scoped asks work best: an object ("document Opportunity"), a theme ("everything related to invoicing"), or a slice of the org ("our validation rules and what they block").
3. The AI researches — you'll see it reading and searching your metadata — then saves the document. The viewer opens on it automatically.
4. Decide right there: keep it (it stays under Documents in the task sidebar) or hit Discard.
5. Iterate in the same conversation: "go deeper on the flows section", "add the permission model", "narrow this to just custom fields". Each revision replaces the saved document.

Documents include diagrams where a picture beats prose: entity-relationship diagrams for object relationship maps (who looks up to whom, master-detail vs lookup) and flowcharts for automation logic and process walkthroughs. Diagrams render live in the chat and in the document viewer, and travel with the markdown when you download it — any Mermaid-aware tool (GitHub, Notion, VS Code) renders them.

The AI documents what it can actually read: it enumerates and inspects your org's cached metadata — objects, fields, flows, validation rules, Apex, permission sets — including a semantic search that finds components by meaning ("custom fields that reference Opportunity") rather than by name.

• Claims about your components come from reading them, not from general Salesforce knowledge.
• Standard-model facts (for example, OpportunityLineItem's master-detail to Opportunity) are labeled as standard Salesforce rather than passed off as org-verified data.
• Every document states its coverage honestly — what was read, what was skipped, and where the metadata cache might lag the live org by a few hours.

Documents are prose, not metadata. They show up under Documents in the task sidebar with a Doc badge, they never appear in the deploy modal, and they are excluded from every deploy package automatically. Generating documentation cannot change anything in your org — it's read-only from start to finish.