← Documentation home

Feature guides

• Overview dashboard
• Change Impact
• Governance
• Data Security & Classification
• Sync History
• Connected Salesforce Org
• Date & time zone
• Notifications
• Metadata Types & scope
• Scheduled Syncs

Overview dashboard

The Overview tab is the landing page of the MetaSync admin dashboard. It answers three questions at a glance: is my org connected, when did it last sync, and did anything risky change. Everything here is read-only summary — you act on it from the other tabs.

Note — Before you connect. Until a Salesforce org is connected, the Overview shows a welcome screen with a three-step outline (Connect Salesforce, Choose destination, Run your first sync) and a Connect your Salesforce org button. See Onboarding: from install to first sync for the full walkthrough.

Banners at the top

• No Confluence destination set — appears when the org is connected but no space is chosen. It points you to Connections → Edit destination. See Connected Salesforce Org.
• High-risk changes need review — a warning that counts unreviewed high-risk changes and links you to Change Impact.
• What’s new — a dismissible banner shown once after MetaSync updates to a new version, listing the highlights of that release. First-time installs are seeded silently (no changelog on day one). Dismissing it is remembered per browser.
• Salesforce connection needs re-authorization — a warning shown app-wide when the stored token was rejected; it carries a one-click Re-authorize Salesforce button. See Re-authorizing your Salesforce org.

Connected-org strip

A single row shows the connected org’s name, a Production or Sandbox lozenge, and the instance URL. MetaSync is a single-connected-org app.

Stat cards

• Org — The connected org name, with the destination space key (e.g. → ACMESF) or No destination set underneath.
• Components — Total components MetaSync has documented, per type, from the last run that extracted each type in full — not a per-run figure. An incremental sync that finds nothing to do leaves the total alone, and the sub-line dates it (counted 3d ago) against the stalest type in the count. Documentation coverage, security gaps, Data Dictionary rows and Setup Audit entries are run metrics, not components, and are excluded. Reads — with Counted after the next full sync until a full sync has completed.
• Last sync — Relative time since the last sync (e.g. 2h ago), with the exact date underneath. Reads Never before the first run.
• Status — The last run’s outcome — Success, With exception, Partial or Failed — with a created · updated page-count summary. Only shown once a sync has run.
• Last scheduled run — The most recent scheduled-job outcome, with its cadence and relative time, so a failed overnight sync isn’t hidden in Sync history. A run still in flight reads Running · in progress · last completed 1d ago (the timestamp belongs to the previous run, not the live one); a schedule that has since been switched off is greyed and marked schedule disabled; one whose next run is more than 15 minutes late is marked next run overdue. Only shown when a schedule has run at least once.

Recent changes & Sync history panels

Two side-by-side cards. Recent changes lists the five latest change-impact entries with a risk badge, component name, type, dependency count and time; the header lozenge counts every retained change, not just the five shown, and a footer line says how many more are waiting in Change Impact. Sync history lists the latest runs with a status lozenge, created/updated counts, timestamp and duration. Both show a friendly empty state before your first sync.

Running a sync

1. Click Sync now in the top-right header bar (present on every tab). It is disabled with a tooltip until an org is connected.
2. The header switches to a live progress readout — spinner, message, percent, and a Cancel button — plus a progress bar under the header.
3. Leave the page if you like; the sync runs server-side across 5-minute trigger windows. A toast reports success or failure when it finishes. See How syncing works.

Full resync — and when you actually need it

Sync now is incremental: it re-extracts only what changed since the last run, which is why a routine sync is fast. Full resync ignores that delta and rewrites every page. It is the slower path — expect a full run rather than a few minutes — so it is not the button to reach for by default.

It exists because some situations an incremental sync cannot fix, however many times you run it. In each of these, MetaSync’s own view of a component has changed while the component in Salesforce has not — so the delta finds nothing to do and the stale page is never rewritten:

• Pages are on older markup after an upgrade. A MetaSync release that changes how a page is laid out normally triggers one automatic full rewrite. If a scope-limited scheduled job runs during that window, only the types in its scope are rewritten — the rest keep the old markup until something else changes them.
• A newly-captured detail should appear on pages that have not otherwise changed. When MetaSync starts reading something it did not read before, only components that also changed in Salesforce are re-published; everything else keeps the older page until a full rewrite reaches it.
• A run was cancelled or failed part-way, leaving some categories published and others not.
• You widened the sync scope and want the newly-included types documented now, rather than as they happen to change.

Note — It rewrites pages; it does not reset your history. A full resync re-publishes page CONTENT from a fresh extraction. It does not delete the change history already recorded against a component, and it does not invent change entries for components that did not change — rewriting a page is not a change in your org, and MetaSync does not report it as one. Team Notes and Team annotations are preserved, exactly as on a normal sync. The one exception is a MetaSync-issued data repair (a purge), which is disclosed on every affected page’s Change history section — dated when it happens, or marked ‘noted here on’ when the repair predates this disclosure mechanism; one such repair in Aug 2026 reset history recorded before it.

Warning — Cancel asks first. Cancel destroys the entire server-side queue — potentially 45 minutes of work on a large org, with no undo and a half-written space until the next full run. So it opens a confirmation quoting exactly what you’d throw away (“12 of 21 work items have published so far”); Keep syncing backs out. Pages already published stay published — the next full sync completes the rest.

Note — A failed read never renders as an empty dashboard. If the admin UI can’t load its data — Overview, Connections, notification settings, metadata selection — it holds an explicit error state with a Retry button rather than rendering a confident blank. On the settings forms, Save stays disabled until a read succeeds: the blank fields are defaults, not your saved configuration, and saving them would have silently disabled your alerting or reversed your sync scope.

Note. The dashboard is admin-only, plus anyone a Confluence admin has granted access under Connections → Additional access. A granted viewer sees Overview, Change impact, Governance, Sync history and Documentation, with admin actions disabled. A granted user given the App admin role sees the whole dashboard and can configure everything — connect the Salesforce org, set the destination, manage schedules and metadata scope, run syncs — but never the Additional access list itself. Everyone else sees a friendly restricted screen — but can still read the published documentation pages in the space. See Connected Salesforce Org and Permissions, scopes & data handling.

Change Impact

The Change impact tab shows what downstream components are affected when your Salesforce metadata changes. After each sync, MetaSync diffs the org against the previous snapshot and, for every changed component, looks up who depends on it — the flows, validation rules, reports and lookup fields that could break. Each change gets a risk rating so you can triage quickly.

Which types are diffed

Change impact covers 22 of the 41 metadata types MetaSync publishes. That is a real limit, not a footnote: a type that is not diffed produces no change entry, no changelog row, and no removal detection — deleting one of them is silent here, and its Confluence page is never bannered as removed. Every type MetaSync publishes appears in exactly one of the four groups below, so you can always tell which side of that limit a type falls on.

• Diffed (22) — Objects, Validation Rules, Flows, Apex Classes, Apex Triggers, Profiles, Permission Sets, Permission Set Groups, Roles, Reports, Dashboards, Workflow Rules, Approval Processes, Assignment Rules, Custom Labels, Connected Apps, External Client Apps, Named Credentials, Layouts, Lightning Pages, Custom Settings and Global Value Sets. The last two publish as part of the Schema group rather than as their own scope toggles, but they are diffed exactly like the rest.
• Folded into their parent (1) — Fields are diffed per field, but the change is reported on the object that owns them, with the changed fields named in the detail panel. (Flow Definitions likewise ride along with their Flow; they are not a separately published type.)
• Not diffed (17) — Record Types, Custom Metadata Types, Field Sets, List Views, Sharing Rules, Muting Permission Sets, Public Groups, Queues, Quick Actions, Custom Tabs, Custom Applications, Email Templates, Report Types, Auth Providers, Remote Site Settings, LWC bundles and Aura bundles. These are still re-extracted and re-rendered on every sync, so their pages stay current — they simply generate no change entries and no removal banners. A page is only rewritten when the rendered content actually changed; when it has not, MetaSync leaves the existing version alone, so the page keeps its earlier Synced timestamp. That is deliberate — it means fewer version-history entries, not a stale page.
• Not applicable (1) — Setup Audit Trail is a running log of org changes, not a set of components, so there is nothing to diff: it publishes as the single Setup Audit Trail page and is rewritten from the org each sync. It neither produces change entries nor needs removal detection.

How risk is computed

Dependencies come from a persisted dependency graph that MetaSync builds across the sync queue — each queue item contributes the edges for the metadata type it just extracted, so no single run needs the whole org in memory. Impact counts only dependent relationships (references, triggered_on, validates, reports_on, workflow_on, approval_on, assignment_on, calls); structural parent/child edges are ignored because they describe schema shape, not breakage risk.

Impact is resolved at field level

Dependents are matched at two levels. First, edges pointing at the changed component itself. Second — when the change carries attribute-level detail — edges pointing at the specific fields that changed (Object.Field). That second pass is what surfaces the flows and validation rules consuming exactly the field you touched, including ones that live on a different object. Consumers are de-duplicated by component, so a flow that reads three changed fields counts once, and the risk thresholds above apply to that de-duplicated count.

When any dependents were found this way, the detail panel calls it out above the dependency chips: “N of these depend on the changed fields — found by matching the specific fields this change touched, not just the component itself. They may live on other objects.”

Note — Subflows list their callers. The graph also carries flow —calls→ flow edges, so modifying a subflow lists every flow that invokes it — as calls in this tab’s detail panel, and as calls (subflow) in the “Referenced by” list on the flow’s published Confluence page. These edges are what let a subflow report the flows that invoke it, so changing it shows the callers it affects.

Risk rules (from the impact-enrichment resolver)

Note. Risk badges read ▲ high, ● medium, ○ low. The backend only assigns low when there is genuinely no downstream impact, and escalates anything worth attention (including risky removals) to medium/high — so the main list never hides something that matters.

The Sync run picklist

At the top-left is a Sync run dropdown. It defaults to the most recent sync so you review one run at a time. Each option is a sync that actually produced impact entries, labelled by its timestamp (and org, if present). Choose All syncs to see every run’s impact together. Next to it are risk filters (All risk / high / medium / low) and review filters (All / Pending / Reviewed), plus an org context badge.

Impactful vs no-impact changes

• Impactful changes (medium/high risk) appear in the main list. Each row has a checkbox for bulk review and is clickable to open a detail panel.
• No-impact changes (low risk) are collapsed into an expandable section labelled N changes with no downstream impact. These rows are display-only — no checkbox, not clickable — because reviewing them is optional. Click the header to expand or collapse.

The detail panel

Clicking an impactful row opens a panel beside the list (aligned to the row). It shows the component name, risk badge, change type, component type, timestamp and org; a What changed before/after list of the attributes that differ; a Fields changed list when a field is known to have changed but its attributes fall outside what MetaSync compares in one pass; a Where to look link to the component’s own Confluence page; a downstream dependencies section listing each dependent with its metadata type and relationship; a References section (what the component itself points to); and a Mark reviewed / Mark unreviewed toggle. Components with no tracked dependencies say so.

Dependency and reference chips read Type · Name · relationship — e.g. Flow · Lead_Router · references. When MetaSync has published a page for that component the chip is a link: click it to open the page in Confluence. Components MetaSync has no synced page for stay as plain text rather than becoming links that lead nowhere.

When the panel admits it isn’t showing everything

Rather than quietly truncating, the panel names each gap:

• +N more attribute changes not shown — The What changed list renders 12 attributes; the rest are counted here.
• This detail is incomplete — An amber note stating that the component has more attributes than MetaSync compares in one pass, and how many were never compared — so changes to those are absent from the list above. Wide objects (hundreds of fields) hit this most often.
• +N more dependents not listed / +N more references not listed — The chips are a 20-item sample; the headline N downstream dependencies count is the true total.
• +N more fields not listed — The Fields changed list renders 15 field names; the rest are counted here.
• +N more changes not analyzed — An amber banner above the list when the run detected more changes than the 100 MetaSync risk-scores. It states the run’s real change total. Those changes are still published to your documentation pages and the next sync starts from the current baseline — they just carry no risk rating here.
• impact unknown (graph unavailable this run) — The dependency graph could not be loaded for that run, so the risk and dependency numbers are defaults rather than analysis.

Note — No attribute detail on a modified component?. The panel says which of three things happened, rather than assuming. (1) The change is in an attribute beyond the set MetaSync compares in one pass — it names how many weren’t compared, and lists the fields that changed where it can. (2) MetaSync compared the component and found no attribute-level difference: Salesforce reported it changed (metadata returned in a different order does this), but nothing MetaSync documents about it moved. (3) There was no baseline yet — the first sync after installing (or after enabling a metadata type) only records one; before/after detail appears from the next sync onward.

Reviewing changes

1. Pick a sync run (defaults to the latest) and optionally filter by risk or review state.
2. Tick the checkbox on each change you’ve assessed, or use Select all in the list header to select every impactful row at once (no-impact rows are never swept in).
3. Click Mark N reviewed (top-right, appears once anything is checked) to mark them all in one action — or open a single row and use Mark reviewed in its panel.
4. Reviewed rows get a Reviewed lozenge. The N pending review count and the sidebar badge reflect only unreviewed impactful changes in the current view.

Note. Change impact data appears only after the first sync that detects metadata changes. If the list is empty, either nothing changed since the last sync or you’re filtering it out. Related concepts: How syncing works and the Overview dashboard.

Governance

The Governance tab is a suite of security and compliance reports covering access, sharing, change history and documentation. Every report reads from one shared snapshot — you build it once, and all twelve are populated from it, together with the Access Review access matrix they depend on. Rebuilding refreshes all of them at once. It does not rewrite the Confluence pages MetaSync publishes (Data Security Posture, Coverage): those are regenerated by the next sync.

The shared snapshot

A snapshot bar at the top controls the build. Choose an FLS scope — PII / sensitive fields only (smaller, faster; uses MetaSync’s field classification) or All fields (every classified field; slower on large orgs) — and whether to include deactivated users (IsActive = false — recommended for access reviews; unchecking it removes them from every report in the snapshot, including the leaver findings in Elevated Access and Inactive Users). Click Build snapshot (or Rebuild snapshot if one exists). Builds run server-side and start within ~5 minutes; you can leave the page. A caption shows when it was last built, how many reports are available, and the FLS scope used.

Note. Click any report card to preview what it covers and the exact columns it produces — even before you build. Every report, including Access Review, is populated by the shared snapshot build.

Tip — Rebuilding preserves the previous snapshot. MetaSync retains a rolling window of the last four snapshots — access reviews are typically quarterly, so four is roughly a year of evidence — and only the fifth-oldest is purged. Rebuilding under the same snapshot id is a replace, not a new version. Note the Governance tab itself always shows the latest snapshot; the retained ones are held so an earlier period’s evidence still exists to be packaged rather than being lost to the next rebuild.

Report cards

Each report is a card with a title, a one-line description, a severity badge (N flagged — the count of critical/high rows, or 0 flagged), and a row count. Cards that aren’t built yet show Not built and open a Preview (blurb + column chips + severity legend + a Build button). Available cards open the full report table.

The reports at a glance

• Access Review — The Start here card. Per-user effective Object (CRUD) and Field-Level Security with grant-source attribution. It is rebuilt as the first step of every snapshot build, because Field-Level Security / PII Access does not compute FLS itself — it pivots this access matrix, so the two must come from the same moment. Its own dedicated UI adds per-user Excel/CSV downloads and a ZIP of everyone — see User Access Matrix.
• Data Security Posture — The org’s data-security scorecard: a 0–100 posture score plus one row per object holding sensitive data. When built, a score card with a gauge and component bars appears at the top of this tab. See Data Security Posture and Data Security & Classification.
• Sensitive Data Discovery — MetaSync’s pattern detector scans every field name/label/type to find likely-sensitive data nobody has classified — the classification gaps. See Sensitive Data Discovery.
• Elevated Access / Risk Register — Every user holding a high-risk capability (Modify All Data, View All, Manage Users, etc.), one row per user × capability. See Elevated Access / Risk Register.
• Inactive Users with Active Access — Users with no login in 30+ days (or never) who still hold access — de-provisioning candidates. See Inactive Users with Active Access.
• Permission Set & Profile Assignment — A bidirectional view of who holds which sets, and which sets are orphaned. See Permission Set & Profile Assignment.
• Field-Level Security / PII Access — Per sensitive field: how many users can read vs edit it, plus encryption and classification. See Field-Level Security / PII Access.
• Sharing & Visibility Summary — Per-object org-wide defaults (internal & external) and the full role hierarchy. See Sharing & Visibility Summary.
• Change History (Setup Audit Trail) — Configuration changes retained beyond Salesforce’s native ~180-day window. See Change History (Setup Audit Trail).
• Org Licenses & Storage — Available vs used licenses (user + permission set licenses, with expiry) and data/file storage headroom — point-in-time capacity figures. See Org Licenses & Storage.
• Installed / Managed Packages — An inventory of the packages installed in the org: one row per package with its name, namespace, installed version, and whether it is managed and/or a beta build. Informational — only beta packages are flagged (low), so it never drives the risk badge. Tier 3, opt-in for the Governance Pack. See Installed / Managed Packages.
• Orphaned / Unused Config — A cleanup checklist of likely-unused config (inactive flows, unused permission sets, unreferenced fields). See Orphaned / Unused Config.
• Documentation Coverage — A coverage score plus a to-document checklist of objects and fields missing descriptions or help text. See Documentation Coverage.

Note. Full column-by-column detail for each report lives in the Reports reference group — the links above go straight there. This tab covers what each report is and how to run it.

Opening and exporting a report

1. Click a report card. If the snapshot has it, the full table opens with any explanatory notes, a row filter, and coloured severity cells (capped at 1000 rows on screen — download for all).
2. Use the Excel or CSV button at the top of the detail view to export that single report.
3. Access Review has its own per-user downloads (Excel / CSV per user) and a Build ZIP / Download ZIP of all users.

Governance Pack (Audit Pack)

1. With a snapshot built, click Export Governance Pack. A modal lists every report with checkboxes — audit-critical reports (Access Review, Data Security Posture, Sensitive Data Discovery, Elevated Access, Inactive Users, Assignments, FLS/PII, Sharing & Visibility, Change History) are pre-selected; hygiene reports are opt-in. A report the latest snapshot could not build is shown disabled and labelled unavailable, with the reason, so you find out before the export rather than from the README afterwards.
2. Ticking Access Review controls whether the per-user workbook ZIP is included; the reports themselves are current either way, because the snapshot built the access matrix.
3. Choose a format — Excel (.xlsx) or CSV — and click Export pack. The pack is one ZIP bundling the selected reports plus a cover sheet, assembled server-side from the snapshot. Nothing is recalculated during the export — rebuild the snapshot first if you need current figures.
4. When it’s ready, click Download ZIP. You can close the modal while it assembles: reopening it picks the finished pack back up.

Note. The full Governance Pack workflow, including what the cover sheet contains, is covered in Audit Pack.

Data Security & Classification

MetaSync scans every synced field’s name, label, type and encryption flag to discover likely-sensitive data — personal identifiers, contact details, financial, health, insurance data and credentials — including fields nobody has classified in Salesforce Data Classification. That discovery powers a sensitive-field inventory, a 0–100 posture score, a published Confluence posture page, risk elevation in Change Impact, and drift alerts when the footprint regresses.

Note — Advisory and read-only. Detection is advisory: every finding carries a confidence level (high/medium/low) and the evidence that produced it. MetaSync never writes classifications back to Salesforce — apply them in Setup → Object Manager → the field → Data Classification. Re-syncing picks the change up and the gap disappears.

How detection works

Figure: detection-pipeline — Field metadata and (optional) Salesforce Data Classification feed the pattern detector; the resulting inventory powers every downstream surface. (illustrated in the in-app documentation).

• Categories — Credentials & secrets, Health data, Financial data, Personal identifiers, Insurance data, Contact details (in severity order).
• Signals — name/label patterns (SSN, Date_of_Birth, Credit_Card_Number, API_Key…), field types that carry contact data by construction (email, phone, address), and encryption (an encrypted field with an unrecognisable name is still flagged, low confidence).
• Guards — the classic false positives are suppressed: opt-out/consent flags, health scores, IP_Address, email templates/domains, booleans, lookups, and record Name fields are never flagged.
• Always current — detection is recomputed from the synced field index every time it’s needed (never stored), so improving pattern catalogs apply to already-synced data immediately.

The posture score

Figure: posture-score-anatomy — Sample composition: 100 − (12 + 8 + 0 + 6) = 74, grade B. Real weights: classification gaps 30, unencrypted high-sensitivity 30, public OWD on sensitive objects 30, undocumented sensitive fields 10. (illustrated in the in-app documentation).

Building a governance snapshot computes the score (see Data Security Posture for the exact formula) and puts a score card — gauge, grade, and per-component deduction bars — at the top of the Governance tab. Grades: A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 40, F below.

Where it shows up

• Governance tab — The posture score card plus the two reports: Data Security Posture and Sensitive Data Discovery. Both are in the Audit Pack by default.
• Confluence — A Data Security Posture page under MetaSync Home (synced with the Documentation group): footprint stats, category breakdown, the classification-gap list with evidence, per-object footprint, and the posture score once a governance snapshot exists. Object, field and Data Dictionary pages also show Detected: <category> badges.
• Change Impact — Changes on objects holding sensitive fields get a Contains sensitive fields chip and risk of at least medium — the tag reflects the object’s current classification, so it appears even when attribute-level change detail isn’t available. When the change detail shows a sensitive field’s own attributes changed, the chip becomes Sensitive field changed and risk rates high. The detail pane lists the object’s sensitive fields either way.
• FLS / Access Review — Detected fields join the sensitive-field universe, so the PII FLS scope monitors who can read/edit them even before they’re classified.
• Data Owner — Fields with a Salesforce Data Classification Field Owner show it in the inventory and on field pages (synced from FieldDefinition.BusinessOwnerId).

Drift alerts

Figure: drift-detection-flow — Each sync compares its sensitive-data footprint with the previous one; only regressions fire. (illustrated in the in-app documentation).

Every sync stores a compact snapshot of the sensitive-data footprint. The next sync compares against it and — only when something regressed — sends a Slack/Teams alert (counts only; field names never leave the app) and lists the affected fields in a Changes since previous sync section on the posture page. The alert is on by default and can be toggled in Notifications.

Only the three regressions raise the red panel and fire the alert.

Note — Growing coverage is not a regression. A field MetaSync has simply never seen before — because you widened the sync scope, or because an earlier incomplete run has since recovered — is coverage change, not drift, and never alerts. When a sync has anything to show under Changes since previous sync, those fields are listed there under a neutral Sensitive-data coverage changed note rather than the red regression panel. Widening what MetaSync can see is an improvement, so it is never reported as a new exposure.

1. Run a sync (with the Documentation scope group enabled) — the Data Security Posture page publishes and detection badges appear on field pages.
2. Open Governance → Build snapshot — the posture score card appears, and the two data-security reports populate.
3. Work the classification-gap list: apply Data Classification in Salesforce Setup for genuinely sensitive fields.
4. Re-sync and rebuild the snapshot — the gaps close and the score climbs.

Sync History

The Sync history tab is the log of every sync run — manual or scheduled — with its duration, page counts and status. It’s where you confirm a run succeeded and where you diagnose one that didn’t.

The runs table

• Status — A lozenge: success (green), success with exception (green — everything published, a page deferred on a transient hiccup and re-publishes next sync), partial (amber — a whole type is incomplete), or failed (red). See below for what partial means.
• Started — The run’s start date and time.
• Duration — How long the run took, in seconds (e.g. 12.4s).
• Created — Number of Confluence pages created in that run. Counts cover content pages; the Changelog page itself is updated by every run and is not counted.
• Updated — Number of Confluence pages updated in that run. Counts cover content pages; the Changelog page itself is updated by every run and is not counted.
• Components — Total components synced across all metadata types in that run.
• (actions) — A Details button when the run recorded a metadata breakdown or an error.

Warning — What “partial” means. A partial status means the run completed but not every metadata type finished — typically because a large sync was split across trigger windows and some part hit a limit or timed out. The pages that did sync are published; re-run to pick up the rest. See Sync appears stuck or partial for stuck or timed-out syncs.

Per-run details modal

1. Click Details on any run to open the Sync details modal.
2. The top shows the org, and four tiles: Status, Duration, Created and Updated page counts, under a line stating what those counts cover: content pages. The MetaSync Changelog page is written after the run record is sealed — its own body prints these counts, so counting the write would mean incrementing the number it publishes — and it is therefore disclosed rather than counted.
3. If the run failed, an Error block shows the captured error message (or a note to check the Forge app logs if none was captured).
4. Metadata synced this run lists each type that produced components, as a card with its count, sorted by volume — plus a total (N components across M types). It counts what this run touched, so an incremental run shows only what changed; the running org-wide total is the Overview Components card.
5. No components synced this run lists the types that ran but found nothing new, as grey chips. It is not a count of what those types hold — an unchanged type is not re-extracted, so the run record carries no population for it; the Overview Components card is where the org-wide totals live. Types the run skipped before extraction do not appear here at all.
6. Also produced by this run lists the run’s non-component outputs — documentation coverage (a percentage), fields missing a classification, Setup Audit Trail entries, Data Dictionary field rows and flow diagrams. These are deliberately kept out of the component total, which they would otherwise inflate with mismatched units.

Warning — A run that says “failed” but published pages. When a single metadata type fails to extract, MetaSync demotes just that type — its pages and change snapshot keep the previous sync’s state, its watermark is held for a re-scan, and no removals are reported for it — while every other type publishes normally. The run is then recorded with an error naming the type and cause, so it is not presented as a clean success. Open Details to see which type it was; a re-run usually clears it. See How syncing works.

Pagination & retention

MetaSync keeps the 20 most recent runs — older runs are dropped, and the caption under the selector says so. The table shows 10 rows per page by default; the Rows per page selector offers 10 or 20, the only sizes that can ever be filled given the 20-run retention. The Previous / Next buttons plus a 1–10 of N counter and Page X of Y show your position.

Note. The Overview dashboard shows a Last scheduled run stat and badges Sync history when the latest scheduled run failed — opening this tab clears that badge. See Overview dashboard and Scheduled Syncs.

Connected Salesforce Org

The Connections tab manages the one Salesforce org MetaSync syncs into Confluence. From here you connect an org, repair a rejected connection, switch to a different org, and change the Confluence destination.

The two connection methods

Step 1 of the connect dialog opens with a Connection method choice, and the choice follows the connection everywhere else on this tab — in the lozenge on the row, in the buttons offered, and in the status wording when something breaks.

• Client Credentials Flow (recommended) — The app’s key and secret sign in as a Run As user named in Salesforce. There is no login prompt, no Callback URL and nothing that expires. Step 1 asks for the org’s My Domain login URL (login.salesforce.com and test.salesforce.com are refused for this method, with the reason under the field), the Consumer Key, the Consumer Secret and a display name; there is no org-type picker. See Onboarding: from install to first sync for the Salesforce-side recipe.
• Web Server Flow — A person signs in on a Salesforce login page as the integration user, and MetaSync keeps the refresh token that sign-in produces. Step 1 shows the Callback URL with a Copy button and the org-type picker (Production/Developer, Sandbox, My Domain URL), then the key, secret and display name.

The connection card

Once an org is connected it appears as a table row with these columns:

• Org — The org display name, with the instance URL underneath and a small method lozenge reading Client Credentials Flow or Web Server Flow. A Client Credentials Flow connection also prints the line Run As <username>, so the user every token acts as is visible without opening Salesforce.
• Type — A Production or Sandbox lozenge.
• Destination — The Confluence space name (or Not set), with the space key underneath.
• API — The Salesforce API version MetaSync reads at. 67.0 reads normally; any other version is flagged amber with a ⚠.
• Last sync — Relative time since the last successful sync.
• Status — A lozenge reading Connected (green), Not yet checked (grey — the hourly credential-health check has yet to report on this connection), or a red label for a rejected connection that names the repair: Needs re-authorization on a sign-in connection, Check app keys on a Client Credentials Flow one. Both point at Re-authorizing your Salesforce org.
• (actions) — An Edit destination button, plus the repair button for the method while the connection is failing: Re-authorize on a sign-in connection, Update keys on a Client Credentials Flow one.

Connecting an org

Connect org is the header button while no org is connected. The dialog runs in three steps, each headed with a Step n of 3 line:

1. Salesforce app. The step opens with the Connection method — Client Credentials Flow or Web Server Flow — and the fields below it change to match. On Client Credentials Flow: the org’s My Domain login URL, the Consumer Key, the Consumer Secret and a display name, with no Callback URL and no org type. On Web Server Flow: the Callback URL for this installation sits above the credential fields with a Copy button — that is the value your Salesforce OAuth app needs on its callback list, and it doesn’t depend on the app, so you can copy it before the app exists — then the org type (Production/Developer, Sandbox, or My Domain URL for an org that blocks the shared login page — this sets the OAuth login domain), the Consumer Key and Consumer Secret from your External Client App (or Connected App — see Onboarding: from install to first sync), and a display name, which follows the org type until you type your own. Click Next: Confluence destination.
2. Confluence destination. The space, home page title, page structure and managed-package choice, with the live page-tree preview — the same fields the Edit destination modal uses, described below. The button reads Next: Connect on Client Credentials Flow and Continue to Salesforce login on Web Server Flow.
3. Connect. On Client Credentials Flow the step carries one button, Test and connect: MetaSync exchanges the key and secret for a token, and on success names the org and the Run As user it signed in as. On Web Server Flow the Callback URL appears once more as a reminder; click Open Salesforce login and complete the login in the tab that opens, and MetaSync polls for completion. Either way the connection finishes by saving the destination from step 2, and MetaSync requests only the api OAuth scope (plus refresh_token on the sign-in method). If Salesforce refuses, the error banner here links straight to The Salesforce login fails or shows an error.

Note — Repairing the connection and switching orgs are separate buttons. Once an org is connected the header carries two buttons, and the first one depends on the method. On a sign-in connection it reads Re-authorize: it signs back in to that same org after an expired or revoked token, a two-step dialog that reuses the app keys saved with the connection — no credential fields and no destination step. On a Client Credentials Flow connection it reads Update keys: a single-step dialog that takes the current app key and secret and a Test and save button, leaving the destination, scope and schedules untouched. The re-authorization banner offers the matching action too — Re-authorize Salesforce or Update app keys. Either way your space, structure, scope and schedules stay exactly as they are (recovery steps in Re-authorizing your Salesforce org). Switch org is the other button: it replaces the connection with a different org through the full three-step dialog, titled Switch the connected org, warning you that finishing it replaces the connection, with step 2 prefilled from the current destination — and it is where you change a connection from one method to the other. There is no separate Disconnect or Delete-connection action; see Switching to a different Salesforce org for the switch walkthrough and its consequences (full re-sync, old pages left in place).

Edit destination modal

Edit destination opens a modal to change where MetaSync publishes. It shares the same destination fields as the connect flow:

• Confluence space — A dropdown of the spaces MetaSync can see, listed as Name · KEY. Requires the read:space:confluence scope; if the list is empty the field says so. MetaSync publishes into an existing space — it does not create one.
• Home page title — The title of MetaSync’s root page, which the whole tree is built under (default MetaSync Home). Renaming it moves the entire tree on the next sync.
• Page structure — Per component (one page per object/flow/rule — granular, more pages, precise change-impact links) or Per type (one index page per metadata type — flatter, fewer pages). See Page structure: per type vs per component.
• Managed packages — Whether to include managed-package (namespaced) components — the filter covers permission sets, permission-set groups, muting permission sets, and LWC/Aura bundles. Off by default. See Managed packages & standard vs custom.

Warning — Consequences of changing the destination. The modal warns that changing the destination republishes on the next sync — MetaSync starts building the new tree then. Existing pages are left in place, not deleted, so a space or structure change can leave the old pages behind. A live page tree preview in the modal shows how the new structure will look.

A live page tree preview below the fields renders the resulting Confluence hierarchy for the chosen structure, so you can see the shape before saving.

Additional access — viewers and app admins

The Additional access card at the bottom of the Connections tab grants MetaSync access to people who aren’t Confluence admins — typically Salesforce admins or architects. Each granted user holds one of two roles: a Viewer reads the documentation and reports; an App admin can also configure and operate MetaSync. The App admin role exists for the common case where the Confluence admin who installed MetaSync doesn’t administer Salesforce: it lets them hand the External Client App / OAuth setup to the person who does, without making that person a Confluence site admin.

1. Switch between the Users and Groups tabs, then open the picker. It lists your Confluence directory with a filter box (by name or email for users); on a large site it shows the first batch with a note telling you to type a name to search the whole directory. Already-granted entries carry a granted lozenge and can’t be re-selected.
2. On the Users tab, choose the role for this grant — Viewer or App admin — next to the Grant button, then tick the people to add and confirm. A manual-entry fallback accepts an account id or group name directly for anyone the directory can’t surface, with a name preview before you commit; manual entries are always granted as viewers.
3. Change a role any time from the Who has access list below: each user row shows their current role and a Make app admin / Make viewer button. Groups always grant read-only viewing — a role can only be given to an individually granted user, so changing group membership in Confluence can never silently create a new app admin.
4. Viewers see Overview, Change impact, Governance, Sync history and Documentation only — the Metadata types, Schedules and Connections tabs are hidden from them. App admins see the full dashboard, minus this Additional access card.

Note — What each role actually means. For a Viewer, configuration actions stay visible but disabled with an explanation rather than failing on click — building a governance snapshot or the ZIP, marking a change reviewed, connecting an org, building an access snapshot. They can still browse and download the latest snapshot and per-user exports. An App admin can do everything a Confluence admin can do inside MetaSync — connect or replace the Salesforce org, edit the destination space, set the metadata scope, create schedules, run and cancel syncs, change notification settings and build every report — with one exception: they can neither see nor edit who has access, including their own role. Both restrictions are enforced server-side; hiding the controls only prevents dead ends.

Warning — Additional access does not control the published pages. This list governs the MetaSync app — the dashboard you are reading this in — and nothing else. Who can read the Salesforce documentation MetaSync publishes into Confluence is decided entirely by your normal Confluence space permissions, exactly as for any other page. Granting someone access here does not give them those pages, and leaving someone off this list does not hide the pages from them. If the documentation should be restricted, restrict the destination space in Confluence — MetaSync deliberately has no override. The same is true of the Live View macro, which checks each viewer against the space it sits on.

Date & time zone

The Date & time zone panel (on the Connections tab) sets the IANA timezone MetaSync uses for every date it writes into Confluence pages — the sync badge on each page header, Content last updated on MetaSync Home, Last modified rows, change-history tables, the Changelog and setup-audit-trail pages — and for interpreting scheduled sync times.

How it’s set

On first dashboard load MetaSync detects the timezone from your Confluence profile and saves it automatically. You can change it any time; an explicit choice is never overwritten by the auto-detection.

What dates look like

All page dates are absolute (e.g. 5 Jul 2026, 1:12 pm AEST) — never relative phrases like Today or 3 days ago, which would go stale the day after a sync, and never raw UTC strings like 2026-07-05T03:12:45Z.

Note. Changing the timezone affects pages from the next sync onward. Existing schedules keep their original timezone until you edit them — the schedule modal shows a notice when a saved schedule’s timezone differs from the current setting. Re-save the schedule to move it onto the current timezone.

Notifications

The Notifications panel (on the Connections tab) sends a message to Slack and/or Microsoft Teams on the sync events you choose. It’s entirely opt-in — nothing is sent until you paste a webhook URL — and every message is status-only: org name, sync status, a truncated error, run id, page counts, per-type counts and duration. No Salesforce record content ever leaves the app.

Two channels

• Slack — Paste a Slack incoming webhook URL (create one in Slack → Apps → Incoming Webhooks). It must be on hooks.slack.com.
• Microsoft Teams — Create a Workflow in Teams → ‘Post to a channel when a webhook request is received’ (the replacement for the retired Office 365 connectors). The generated URL is on *.logic.azure.com or *.powerplatform.com. Teams messages render as an Adaptive Card.

Each channel has its own Test button that sends a one-off test message so you can confirm the wiring before saving. Leave a URL blank to disable that channel. The event choices below apply to both channels.

Events

• A sync fails or completes partially — On by default. Fires on a transition into failure, on a genuinely different error, and re-reminds at most once every 24h while a sync stays broken — it won’t spam a channel every 5-minute tick.
• A sync recovers after a failure — On by default. One message when a sync succeeds after a prior failure.
• The Salesforce connection expires or is revoked — On by default. One message per outage, driven by the hourly credential-health check. See Re-authorizing your Salesforce org.
• Data-security drift is detected — On by default. Fires when a sync finds the sensitive-data footprint regressed since the previous sync — a removed classification, removed encryption, or a new classification gap on a field MetaSync already knew about. Newly-seen sensitive fields are coverage change and deliberately do not alert. Counts only; field names never leave the app. The affected fields are listed on the Data Security Posture page. See Data Security & Classification.
• A sync completes successfully — Off by default (opt-in). With the indented Only when pages changed option (on by default), a no-change run stays silent. A recovery message takes precedence — you won’t get both for the same run.
• Weekly summary digest — Off by default (opt-in). A once-a-week roll-up: run counts by outcome, total pages, top orgs, and whether the latest sync is currently failing. The first digest arrives one week after you enable it, and a quiet week still sends (“no syncs ran”).

Note — New permissions on update. Adding Teams widened MetaSync’s outbound network permissions (*.logic.azure.com, *.powerplatform.com). After updating, a Confluence admin must approve the new access under Manage apps → MetaSync, the same as any Marketplace permission change.

Metadata Types & scope

The Metadata types tab controls which Salesforce metadata MetaSync extracts and publishes. Narrowing the scope keeps syncs fast and your Confluence space focused. The selection applies from the next sync — manual or scheduled.

How the grid works

Types are organised into cards, one per group. Each card has a master toggle (turns the whole group on/off, shows Partial when only some are on) and per-type chips you click to select or deselect individually. Above the grid, Select all / Clear all buttons and a N of M types selected counter, plus a Save selection button. Everything is on by default.

The scope groups and what each includes

Metadata scope groups (verified against App.tsx METADATA_GROUPS)

Note. The Documentation group’s toggles feed the aggregate pages — the Data Dictionary, Documentation Coverage score, Setup Audit Trail, and the Data Security posture page. Turn them off and those pages (and macro tabs) stop updating.

For a field-by-field reference of what each type’s published Confluence page contains, see the Metadata reference group — e.g. metadata reference. If a type you expect isn’t syncing, see Why is a component or type missing?.

Object selection

The underlying scope also supports restricting to specific objects by API name (stored as objectNames). Deselecting the Custom Object / Custom Field types stops object syncing entirely; leaving them on syncs the objects in scope.

Saving a selection

1. Toggle groups or click individual type chips until the selection matches what you want documented.
2. Click Save selection. A success banner confirms it applies from the next sync (manual or scheduled).
3. Pages for de-selected types are no longer updated but stay in Confluence — use Housekeeping below to flag them.

Housekeeping — pages no longer in scope (scope-prune)

Pages can go stale in more than one way, and the Housekeeping tool at the bottom of the tab finds both kinds. It labels only — MetaSync never deletes Confluence pages, so you stay in control of removal.

• De-scoped type — You turned a metadata type off, so its published pages stay put and quietly stop being updated. Listed under that type’s name.
• Leftover / duplicate — A page of a type that is still enabled, published under a title that no longer matches any current component — typically left behind by a rename or a title re-key. Detected for Profiles and Permission Sets, by comparing published page titles against the complete current title set for that type. Pages already carrying the banner are skipped, and detection is disarmed entirely when the title set is empty (a never-synced or unreadable registry must not flag everything).
• Stale page — A recognised placeholder title that never corresponds to a real component (for example Validation Rules: Unknown).

1. Click Find pages no longer in scope. MetaSync scans and lists each candidate with a category lozenge. Nothing is pre-checked — labeling pages is an explicit opt-in.
2. Tick the ones you want labeled, then click Label N pages as no longer updated. Each gets a ‘no longer updated’ note prepended. The result line separates newly labeled pages from ones that were already labeled (a prior run whose browser timed out can still have completed server-side) and any that could not be read.
3. On very large spaces the scan is capped — an amber note tells you to re-scan after labeling to find more.

Note. The label is reversible: it prepends a note to the page and nothing else. Your selection is also re-derived server-side before anything is labeled, so a stale list from an old preview can’t stamp the wrong pages.

Note. See Removed & out-of-scope pages for how MetaSync handles pages whose Salesforce component was deleted, versus pages you’ve de-scoped here.

Scheduled Syncs

The Schedules tab automates syncs so your Confluence documentation stays current without manual runs. Schedules use Forge scheduled triggers — no external cron server is needed.

The schedule list

• (toggle) — An enable/disable switch — flip it to pause or resume a schedule without deleting it.
• Org — The org the schedule syncs (the single connected org).
• Cadence — Hourly, Daily, Weekly, or Custom cron.
• Time — The time of day for daily/weekly runs (in the schedule’s timezone), or the cron expression for custom schedules.
• Scope — A lozenge showing which metadata the run covers — All types, or a narrowed group like Automation only.
• Next run — When the schedule is next due to fire.
• Last result — A lozenge: Never run, Running…, success, or a failure state.
• (actions) — An Edit button (pencil) to change the schedule.

Creating or editing a schedule

1. Click New schedule (or the pencil to edit an existing one).
2. Choose the Org, then a Cadence (Hourly / Daily / Weekly / Custom cron).
3. For daily/weekly, set a Time of day. For Custom cron, enter a cron expression — it’s validated against Forge scheduler limits. Both are interpreted in the configured display timezone (Connections → Date & time zone); the field label shows which timezone applies.
4. Choose a Scope: All metadata types, Schema only, Security & Access only, or Automation only. Narrowing scope keeps scheduled runs fast.
5. Click Create schedule / Save changes.

Tip — Editing a schedule keeps its run history. Saving an edit merges your changes onto the stored job rather than replacing it, so Last result and Last run survive — an edited schedule keeps its run history instead of looking as though it had never run.

Warning. Choosing Hourly shows a note: hourly runs on large orgs can approach Forge invocation limits. MetaSync uses incremental extraction after the first full sync to keep each run fast.

Enabling and disabling

Use the toggle in the first column to enable or disable a schedule instantly. A disabled schedule keeps its settings but won’t fire.

How schedules interact with the 5-minute engine

A Forge scheduled trigger checks for due jobs every 5 minutes. When a job is due it queues the sync, which then runs across one or more 5-minute trigger windows (large orgs span several). Because of this, a run starts within 5 minutes of its scheduled time, not exactly on it. Failed scheduled jobs are recorded in Sync history, and the Overview surfaces the latest scheduled outcome. See How syncing works for the full engine model.

Note. A common pattern: a daily All types run for full coverage, plus an hourly Automation only run during active build phases when flows and Apex change frequently.