AI documentation for your Salesforce org

Role-specific Salesforce documentation, designed to be generated by AI from your real org.

Clionyx is designed to read your Salesforce configuration and write plain-language, role-specific documentation grounded in how your org actually works, so the docs reflect the real build instead of a generic template. Named after Clio, the muse of history.

Clionyx in the Digadop family on digadop.ai ›

Who it is for

Salesforce documentation owners, admins, and enablement teams whose org docs go stale the moment a field or validation rule changes.

How it works

Connect

Salesforce OAuth
Generate

AI is designed to read your config
Review

designed for your team to approve
Deliver

HTML and print-ready PDF

What it is being built to do

Grounded in your org

Designed to read your org configuration and write plain-language help for every object, grounded in how your org actually works rather than a generic template.

Role-specific

Designed so the same object reads one way for a salesperson and another for a support agent, scoped to the layouts, record types, and fields each role can see.

Traceable claims

Designed to trace every factual claim to a specific element of your configuration, so a reviewer can check any statement against the org instead of taking it on trust.

Structured per object

Structured output per object: what it is for, your process steps, the fields you fill in, what connects to it, what runs automatically, what blocks a save, and a decoder for your real validation messages.

Written for the reader

Field labels instead of API names, and the effect of automation ("when you mark Closed Won, an invoice task is created") instead of the mechanism.

On screen and in print

On-screen collapsible sections plus a print-ready PDF leave-behind.

Paragraph-by-paragraph review

Designed for your team to review each document paragraph by paragraph (approve, edit, pin, reject, comment), with those decisions remembered so your corrections compound across versions.

Roles and tailoring

A standard role library with an automatic profile-to-role proposal, plus per-role tailoring: glossary, suppression, injected content, emphasis, and tone.

Designed to stay current

Designed to detect org changes and refresh the affected docs, publish approved help into Digadop Help in context, and generate plain-language release notes from a change ledger.

Sample output

A page of docs, written for the reader

Doc Opportunity, documented for a Sales rep

What it is for: Tracks a deal from first interest to closed.
Stage: Move it along as the deal progresses. "Closed Won" is final.
Amount: The expected revenue. Required before you can submit for approval.
What happens automatically: Marking Closed Won creates an invoice task for Finance.

Illustrative example. Clionyx is designed to write field labels and the effect of automation in plain language, grounded in your real configuration.

What the beta includes

Availability: Clionyx is not yet generally available, and no Salesforce org can be connected to it yet. This describes Clionyx as designed and being built, not a service you can use today.

Trust

Built to be safe to connect.

Standard Salesforce OAuth

Designed to connect through standard Salesforce OAuth.

AI on AWS Bedrock

In production, generation will run on Amazon Bedrock, and every document is reviewed on your terms before anyone relies on it.

Documentation for the people your org serves

Clionyx is being built to read a Salesforce org and produce documentation of how to use it, written for the specific kinds of people the org serves. Instead of listing what exists (a static metadata inventory), it is designed to explain how each part of the org works and how each type of user gets their job done in it. To keep the writing audience-aware, Clionyx is designed to recognize the org's real personas from how the org is configured, and to tailor the documentation to each one. That persona recognition is the input that makes the docs fit the reader; it is not the product. Clionyx is designed to document functionality and respect the access each reader already has; it is not an access-audit tool.

What makes Clionyx different from writing docs by hand

Three things, by design. First, documentation is generated from your org's actual configuration, so it describes how your org really works rather than a generic template. Second, it is role-specific: the same object reads one way for a salesperson and another for a support agent, because each document is scoped to what that role can see and do. Third, it is meant to stay current: as your org changes, Clionyx is designed to refresh the affected documentation, and your own edits carry forward into every future version. Automatic refresh is in development and does not run yet.

Why every document is written in plain language

Every document is designed to be written in plain language for the reader. It uses field labels rather than internal API names, and it describes the effect of automation ("when you mark Closed Won, an invoice task is created") rather than its mechanism. Each section is designed to expand or collapse so a reader can jump straight to what they need.