SyncOnAI360

Supported Metadata

Exactly which Salesforce metadata SyncOnAI 360 covers.

What is read into the repository, what has full source, what the builders can edit, what is not read at all, and where impact analysis applies, stated plainly before you buy.

Workspace security

Settings · Security

  • Configuration onlyMetadata and code. CRM records stay in Salesforce.
  • Isolated per customerEnforced by the database and tested every release.
  • Keys in Google Cloud KMSCredentials encrypted under a per-customer key.
  • Second admin for productionThe author can never approve their own change.
  • Hosted in the United StatesEvery subprocessor listed with its region.

In one paragraph

SyncOnAI 360 reads more than twenty Salesforce metadata types into each org's repository, including objects, fields, layouts, Lightning pages, Apex, Lightning Web Components, Flows, validation rules, permission sets and profiles. It edits Flows, Lightning pages, components and Apex on visual builders, and does not read CRM records or hidden managed package source.

Metadata types read
20+Metadata types read
Visual builders: Flow, Lightning page, LWC, Apex
4Visual builders: Flow, Lightning page, LWC, Apex
CRM records read into the repository
0CRM records read into the repository
Package source is shown as hidden, never as missing
HiddenPackage source is shown as hidden, never as missing

01The problem

Why metadata coverage matters before you choose a tool

Every Salesforce tool covers some metadata types and not others. Finding out after rollout that the tool cannot read your Flows or your components is an expensive surprise.

  1. 01

    Coverage left vague

    "Supports Salesforce metadata" can mean anything from five types to all of them.

  2. 02

    Read is not edit

    A tool may read a type without being able to build or change it.

  3. 03

    Silent gaps

    Unsupported types are often just missing, with nothing telling you.

  4. 04

    Package confusion

    Managed package code is hidden by its publisher, and tools treat that differently.

02read

Which Salesforce metadata types are read?

Objects, fields, record types, layouts and Lightning pages. Apex classes and triggers with full source. Every file of each Lightning Web Component. Flows, validation rules, permission sets and profiles. Email templates, value sets, approval processes, queues, reports, dashboards and sharing rules. Apex test coverage from the org's last test run.

Each sync shows counts per metadata type while it runs, so you can see exactly what was read from your org.

  • Data model: objects, fields, record types
  • UI: layouts and Lightning pages
  • Code: Apex and LWC with full source
  • Automation, security and more

Workspace security

Settings · Security

  • Configuration onlyMetadata and code. CRM records stay in Salesforce.
  • Isolated per customerEnforced by the database and tested every release.
  • Keys in Google Cloud KMSCredentials encrypted under a per-customer key.
  • Second admin for productionThe author can never approve their own change.
  • Hosted in the United StatesEvery subprocessor listed with its region.

03not read

What does SyncOnAI 360 not read?

Your records: accounts, contacts, opportunities, cases and the rest stay in Salesforce, and record queries run live when needed. The source of managed package code that Salesforce hides cannot be read, so those components are listed and shown as hidden by their publisher, never as missing.

Coverage equals what the last sync retrieved, and the product never treats the absence of something in the repository as proof that it does not exist in the org.

  • No CRM records
  • Hidden package source shown as hidden
  • Absence never treated as proof

Acme Production

Org health · synced 4 minutes ago

82

Health · B

Health

82

Confidence

74

Coverage

91

Apex coverage 78%, from the org's last test run

  • 3 Flows on Case run on the same trigger
  • 11 Apex classes below 75% coverage
  • Managed package source hidden by Salesforce: 2 packages

04edit

Which Salesforce metadata can be built and edited?

Flows on a canvas matching Salesforce's Flow Builder; Lightning pages drawn as they render; Lightning Web Components with a library of more than 700 components; and Apex classes and triggers through Apex Logic, with edits that would not compile refused. The chat also drafts other configuration, such as validation rules and fields, as proposals.

Some parts are view-only for now: in Flows, Decision outcomes, Screen components, Wait events, Transform mappings and orchestration steps; in Lightning pages, the template and advanced visibility rules.

  • Flows, pages, LWC and Apex on builders
  • Other configuration through proposals
  • View-only areas stated

Flow: Case_Intake_Route

Record-triggered · after save

StartCase created
Get RecordsGet Queue by region
DecisionRegion?
Update RecordsAssign to queue

05impact

Where does impact analysis apply?

Cascading dependency checks on proposals cover fields, Flows, Apex classes and triggers, objects, Lightning Web Components and validation rules. For other types, the check warns that impact analysis is not available yet rather than reporting no impact.

Deploys go through the Salesforce Metadata API, so anything Salesforce can deploy that way can be proposed, validated and approved.

  • Impact on fields, Flows, Apex, objects, LWC, validation rules
  • A warning where impact is not yet available
  • Deploys through the Metadata API

Proposal: Case intake fault handling

Acme Production

Checks passed
  • Validated against the org without changing it
  • No component outside the change is modified
  • Apex tests pass, coverage 81%
  • No freeze window in effect
  • Policy: production requires a second admin

Blast radius

  • 2 Flows read Case.Priority
  • 1 report filters on it
  • Case_Intake_Route assigns from it

Risk: medium

06plan

How do you check coverage for a specific project?

Before a project, list the metadata types it will touch and check each against this page: read with full source, editable on a builder, or proposed through the chat. Then connect a sandbox and confirm the counts the sync reports for those types.

If a type you rely on is view-only, plan that part of the work in Salesforce's own tools; the repository and the change history still include it once the org is synced.

  • List the types a project touches
  • Confirm counts on a sandbox
  • Plan view-only parts separately

Command Center

Org portfolio

5

Connected orgs

78

Average health

3

Need attention

  • Global Sales · ProductionProd

    12 open findings · Deploy approved 2h ago

    86

  • Service EMEA · ProductionProd

    31 open findings · Change made outside pipeline

    71

  • Partner Portal · ProductionProd

    18 open findings · Audit finished 20m ago

    79

  • Global Sales · UATSandbox

    14 open findings · Proposal validated

    84

  • Service EMEA · DevSandbox

    36 open findings · Sync running

    68

07How it works

Checking coverage for your org

See it on your own org before you commit.

  1. 01

    Connect a sandbox

    Authorise it with Salesforce OAuth.

  2. 02

    Watch the sync

    See counts per metadata type as it runs.

  3. 03

    Explore

    Search components and open their lineage.

  4. 04

    Try a change

    Build something and see the checks and validation.

08Before and after

Metadata coverage, vague versus stated

Without

With SyncOnAI 360

"Supports Salesforce metadata"

Every type listed, read and edit separately

Unsupported types silently missing

Counts per type shown during sync

Package code treated as clean

Hidden source shown as hidden

No impact means unknown

A warning where impact is not available

10Questions

Frequently asked questions

More than twenty, including objects, fields, record types, layouts, Lightning pages, Apex, Lightning Web Components, Flows, validation rules, permission sets, profiles, email templates, value sets, approval processes, queues, reports, dashboards and sharing rules.

No. Records stay in Salesforce; record queries run live when needed.

Not where Salesforce hides it. Those components are listed and shown as hidden by their publisher.

Most. Decision outcomes, Screen components, Wait events, Transform mappings and orchestration steps can be viewed but not yet changed.

Not yet. Templates and advanced visibility rules are not editable.

Fields, Flows, Apex classes and triggers, objects, Lightning Web Components and validation rules. Other types show a warning that impact is not available yet.

Through the Salesforce Metadata API, after validation against the org and approval.

Yes. Connect a sandbox on the Free plan and watch the sync's counts per metadata type.

Yes. Coverage grows as new types are added, and the changelog records what shipped and when. The sync's counts per type always reflect what was actually read from your org.

Package components are listed with the rest of the org. Where the publisher hides the source, the component is shown as hidden rather than missing, and dependency answers say so.

Start in 5 minutes. No card required.

Connect your Salesforce org. Run your first health scan. Ask your first question. See what you've been missing.

  • Anthropic
  • OpenAI