# Exactly which Salesforce metadata SyncOnAI 360 covers. > 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. Source: https://synconai360.com/features/supported-metadata ## Key facts - **20+**: Metadata types read - **4**: Visual builders: Flow, Lightning page, LWC, Apex - **0**: CRM records read into the repository - **Hidden**: Package source is shown as hidden, never as missing ## 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. - **Coverage left vague.** "Supports Salesforce metadata" can mean anything from five types to all of them. - **Read is not edit.** A tool may read a type without being able to build or change it. - **Silent gaps.** Unsupported types are often just missing, with nothing telling you. - **Package confusion.** Managed package code is hidden by its publisher, and tools treat that differently. ## 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 ## 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 ## 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 ## 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 ## 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 ## Checking coverage for your org 1. **Connect a sandbox.** Authorise it with Salesforce OAuth. 2. **Watch the sync.** See counts per metadata type as it runs. 3. **Explore.** Search components and open their lineage. 4. **Try a change.** Build something and see the checks and validation. ## 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 | ## Who needs this page - **Evaluation teams.** Check coverage against your org's real make-up before you commit: connect a sandbox free and watch the count for each metadata type as the sync runs. - **Salesforce developers.** Know which metadata has full source, which can be edited on a builder and which goes through a proposal, so work is planned around what the product really does. - **Salesforce architects.** See where impact analysis applies and where it warns instead, so a dependency answer is trusted for the right types and questioned for the rest. - **Consultancies.** Tell a client up front what will be read from their org and what will not, records included, which is usually the first question their security team asks. ## Frequently asked questions ### Which Salesforce metadata types does SyncOnAI 360 support? 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. ### Does it read our records? No. Records stay in Salesforce; record queries run live when needed. ### Can it read managed package code? Not where Salesforce hides it. Those components are listed and shown as hidden by their publisher. ### Can it edit every Flow element? Most. Decision outcomes, Screen components, Wait events, Transform mappings and orchestration steps can be viewed but not yet changed. ### Can it change Lightning page templates? Not yet. Templates and advanced visibility rules are not editable. ### Which types get impact analysis on a proposal? Fields, Flows, Apex classes and triggers, objects, Lightning Web Components and validation rules. Other types show a warning that impact is not available yet. ### How are changes deployed? Through the Salesforce Metadata API, after validation against the org and approval. ### Can we check coverage on our org first? Yes. Connect a sandbox on the Free plan and watch the sync's counts per metadata type. ### Does supported metadata change over time? 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. ### How are installed packages handled? 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.