MetaSync for Confluence — Documentation
Living Salesforce documentation in Confluence

← Documentation home

Reports reference

Elevated Access / Risk Register

Tier 1 — audit-critical (included in the Audit Pack by default). The “who can do dangerous things” register. It answers the auditor question: which users hold high-risk system capabilities, and how did they get them? One row per user × elevated capability, so a single over-powered user surfaces once for each dangerous permission they hold — each is individually reviewable and sign-off-able.

Columns

Column Meaning
Username The user’s login username (falls back to the user Id if the username is unavailable).
Full Name The user’s display name.
Active Whether the User record is active (check mark = active).
Last Login Timestamp of the user’s last login (blank if they never logged in).
Profile The user’s profile name.
Capability The single elevated capability this row is about (e.g. Modify All Data).
Grant Source Every permission set / profile that contributes this capability to this user, joined with ; . Profile-backed sets show as Profile: <name>; standalone sets as Permission Set: <name>.
Severity Risk level for this user × capability (see below).
Days Since Login Whole days since last login; blank when the user never logged in.
Notes Free-text flags such as ex-employee candidate (inactive user), stale login (90+ days), never logged in.

Severity logic (exact)

A user is treated as stale when they are inactive, have never logged in, or have not logged in for more than 90 days.

Note — How rows are counted and sorted. Only critical and high rows count toward the report’s flagged/risk total and the card’s red badge; medium/low/none are informational. Rows sort by severity descending, then by days-since-login descending (never-logged-in treated as most stale).

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Inactive Users with Active Access

Tier 1 — audit-critical (in the Audit Pack by default). Lists accounts that are dormant yet still hold access — prime de-provisioning candidates. It answers: are there leavers, abandoned accounts, or over-provisioned integration users still able to act in the org?

Columns

Column Meaning
Username Login username (falls back to user Id).
Full Name Display name.
User Type Salesforce UserType, e.g. Standard (interactive human) vs non-interactive types (integration / automated process).
Active Whether the User record is active.
Last Login Last login timestamp (blank = never).
Days Since Login Whole days since last login; blank when never logged in.
Inactivity Bucket never, 90d+, 60-90d, or 30-60d.
Profile Profile name.
Role Role name (or an em dash if none).
Assigned Perm Sets Count of permission sets assigned to the user.
Holds Elevated Whether the user holds any permission set carrying an elevated capability (same set as the Risk Register).
Severity Risk level (see below).
Notes Flags such as holds elevated capability, never logged in, non-interactive user type.

Severity logic (exact)

“Standard” here means UserType === 'Standard' (an interactive human account). Non-Standard types (integration, automated process, etc.) are expected never to log in, so inactivity alone does not escalate them.

Warning — Why integration users are down-weighted. A never-logged-in account holding Standard interactive access is high-signal — it usually means an over-provisioned integration user or an abandoned account. But non-interactive user types are only escalated to critical when they also hold an elevated permission set, never for inactivity alone.

Flagged count and sort match the Risk Register: only critical/high count; rows sort by severity then days-since-login descending.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Permission Set & Profile Assignment

Tier 1 — audit-critical (in the Audit Pack by default). A bidirectional “who holds what” view presented as two tables. It answers: which permission sets are assigned to nobody (or only to inactive users), and which sets does each user hold? See Permission Sets and Profiles.

Primary table — by permission set (Direction B)

Column Meaning
Permission Set Set API name. Profile-backed sets (the hidden set behind a profile) are shown as Profile: <profile name>, not their internal Id.
Label Friendly label (for profile-backed sets, the profile name).
Type PermissionSet.Type (e.g. blank for a regular set, Group for a Permission Set Group component set).
Profile-Backed Whether the set is owned by a profile (IsOwnedByProfile).
Active Assignees Distinct active users assigned.
Inactive Assignees Distinct inactive users assigned.
Total Assignees Distinct users assigned (active + inactive).
Orphan Status Orphaned, OnlyInactive, or Healthy (see below).
Severity Derived from Orphan Status (see below).
Last Modified The set’s last-modified timestamp.

Orphan status & severity (exact)

Note. Neither Orphaned (medium) nor OnlyInactive (low) counts toward the flagged total — only critical/high do — so this report typically shows 0 flagged even when it surfaces cleanup candidates. Primary rows sort by severity descending, then by total assignees ascending (orphans / low-use sets first).

Secondary table — By User (Direction A)

Column Meaning
Username Assignee username (falls back to user Id).
Full Name Assignee display name.
Active Whether the assignee is active.
Profile Always an em dash — the by-user query carries only the assignee’s name/username, not their profile.
Permission Set The assigned set (profile-backed sets shown by profile name).
Assigned Via Direct for a direct assignment, or Group: <PSG label> when the assignment comes through a Permission Set Group.
Type The set’s PermissionSet.Type.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Data Security Posture

Tier 1 — audit-critical (in the Audit Pack by default). The org-level how exposed is our sensitive data view: one row per object holding sensitive fields (Salesforce-classified or MetaSync-detected — see Data Security & Classification), combining field sensitivity with the object’s org-wide defaults, encryption and documentation. Its headline is the 0–100 posture score, shown as a score card at the top of the Governance tab and as the report’s secondary Scorecard sheet.

The posture score

Figure: posture-score-anatomy — Illustrative composition. Each component’s deduction = weight × its risk ratio. (illustrated in the in-app documentation).

Score = 100 − the four deductions, clamped 0–100. Grades: A ≥ 90, B ≥ 75, C ≥ 60, D ≥ 40, F below.

Score component Weight Risk ratio
Classification coverage 30 Detected-sensitive fields with no Salesforce classification ÷ all detected-sensitive fields.
Encryption of high-sensitivity data 30 Unencrypted high-sensitivity fields ÷ all high-sensitivity fields. High sensitivity = SF-classified high PII, or a high-confidence detection in Credentials/Health/Financial/Personal identifiers.
Org-wide defaults on sensitive objects 30 (Public read/write objects + 0.5 × public read-only objects) ÷ the sensitive objects whose OWD was actually read. Objects the OWD query didn’t return are excluded from the denominator, not assumed private, and the shortfall is stated in the Notes.
Documentation of sensitive fields 10 Sensitive fields with no description or help text ÷ all sensitive fields.

When a component can’t be measured

An unmeasured component deducts nothing, which would silently turn missing evidence into a high score — an org whose OWD couldn’t be read once published 100/100, grade A. So a component MetaSync could not evaluate is never scored as a pass:

Note — A 100 with no sensitive data says so. When the scan finds no sensitive fields at all, every ratio has a zero denominator and the score is 100 by construction. The page states this explicitly — it reflects the absence of findings in the sync scope, not a demonstrated control. Don’t hand that figure to an auditor as evidence of protection.

Warning — The object universe is the sync scope. Both this report and Sharing & Visibility evaluate the objects in MetaSync’s sync scope (the Data Dictionary index), never the whole org — and each states its object count in the Notes. Objects excluded from the sync scope are not evaluated and the report makes no claim about them. Widen the scope in Metadata Types & scope before treating either as org-wide coverage.

Columns

Column Meaning
Object / Label The object holding sensitive fields (API name + label).
Sensitive Fields How many of its fields are sensitive (detected or classified).
Categories Detected categories with counts, e.g. Personal identifiers ×3; Financial data ×1.
Classification Gaps Detected-sensitive fields on this object with no Salesforce classification.
Unencrypted High-Sensitivity High-sensitivity fields stored unencrypted.
Internal OWD / External OWD The object’s org-wide defaults (Private, Public Read Only, Public Read/Write, …). n/a when OWD could not be read.
Severity Row risk (see below).
Notes Plain-language flags, e.g. public read/write OWD over sensitive data, 2 high-sensitivity field(s) unencrypted.

Severity logic (exact)

Secondary table — Posture Scorecard

The export carries a second table (its own sheet in Excel, a # Posture Scorecard section in CSV) that shows the score arithmetic one row per component, so the headline number can be audited rather than trusted. Its sheet title states the score and grade — e.g. Posture Scorecard — 68/100 (grade C) — and says so explicitly when there was nothing to score.

Column Meaning
Score Component Which of the four components this row scores: classification gaps, unencrypted high-sensitivity fields, OWD exposure, or documentation.
Finding The measurement in plain language — what was found for this component, or why it could not be measured.
Weight The component’s maximum contribution: 30 for classification gaps, unencrypted high-sensitivity and OWD exposure; 10 for documentation. They sum to 100.
Deduction Points actually deducted, 0–Weight. A component that could not be measured deducts nothing and is badged Not measured rather than scored 0, so missing evidence never inflates the score.
Severity Row risk for this component, using the same badge scale as the primary table.

Note — Secondary sheet: Posture Scorecard. Columns Score Component · Finding · Weight · Deduction · Severity, one row per component, with the score and grade in the sheet title. Unmeasured components carry their Not measured state through to the sheet, and the sheet title reflects the same ceiling notation as the page. The same payload drives the Governance tab’s score card and the published posture page.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Sensitive Data Discovery

Tier 2 — audit-critical (in the Audit Pack by default). The org’s sensitive-field inventory: one row per field that is either classified in Salesforce Data Classification or flagged by MetaSync’s pattern detector (see Data Security & Classification). Its headline value is the classification gap — fields that look sensitive (SSN, salary, medical history, API keys…) that nobody has classified, the blind spot native Salesforce reporting can’t show.

Columns

Column Meaning
Object / Field / Label / Data Type The field’s identity.
Source Detected (pattern detector only), Classified (Salesforce Data Classification only), or Detected + Classified.
Detected Category Credentials & secrets, Health data, Financial data, Personal identifiers, Insurance data, or Contact details.
Confidence high (unambiguous pattern, or a corroborated match), medium (name pattern or contact field type alone), low (encrypted field with no recognisable name).
Evidence The signals behind the detection, e.g. name matches "social security number"; field is encrypted.
SF Security Classification / Compliance Group The org-set Data Classification values, when present.
Data Owner The field’s Data Classification owner (BusinessOwnerId resolved to a user/group name). Populates after the first schema sync on v17+.
Encrypted Whether the field is encrypted.
Classification Gap Check mark = detected as sensitive but carrying no SecurityClassification or ComplianceGroup.
Severity Row risk (see below).
Notes Plain-language flags, e.g. possible plain-text secret — consider Named Credentials or encryption.

Severity logic (exact)

Tip — Working the gap list. Sort by Severity, review the Evidence column, and apply Data Classification in Salesforce Setup for the genuine findings. After the next sync + snapshot rebuild the gaps close and the posture score climbs.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Field-Level Security / PII Access

Tier 2 — audit-critical (in the Audit Pack by default). The field-centric inverse of the User Access Matrix: instead of “what can this user see”, each sensitive field becomes a row showing its exposure — how many users can read it vs edit it, whether it is encrypted, and how it is classified. Field-Level Security (FLS) is Salesforce’s per-field read/edit control. This report serves GDPR / Australian Privacy Act (APP 11) / data-protection reviews. See PII & data classification.

Scope

The report follows the governance build’s FLS scope toggle:

Columns

Column Meaning
Object Object API name.
Field Field API name.
Label Field label (from the Data Dictionary).
Data Type Field data type.
MetaSync Classification PII (<subtype>) when flagged PII, else sensitive when in the sensitive set, else blank.
SF Security Classification Salesforce’s own field SecurityClassification value (blank if unset).
Compliance Group The field’s compliance group tag, if any.
Encrypted Whether the field is encrypted.
Readers Count of distinct users with effective read.
Editors Count of distinct users with effective edit.
Top Readers (sample) A capped sample of up to 5 reader usernames (the full list is not in this summary).
Severity Exposure risk (see below).
Classification Gap True when MetaSync flags the field as PII but Salesforce has no SecurityClassification set.
Notes Flags such as PII field not encrypted, the classification-gap note, and editable by N users.

Severity logic (exact)

Both the broad-read and broad-edit thresholds are 25 users (> 25, i.e. 26 or more). Let PII = the field is in the sensitive/PII set.

Warning. Severity here weighs exposure, not encryption alone — so 0 flagged does not mean no PII risk. An unencrypted PII field read by a handful of users lands on MEDIUM and is not counted as flagged. That is deliberate: flagging every unencrypted email/phone/address field HIGH regardless of who could read it made the flagged count roughly equal to the field count and drowned the genuinely broad-readable findings. The consequence is that an org can hold dozens of unencrypted PII fields and still show 0 flagged, because none of them is readable by more than 25 users. Read the Encrypted and Readers columns, not only the flagged total; the Classification Gap column and Sensitive Data Discovery cover the classification side.

Note. Only critical/high count toward the flagged total. Rows sort by severity descending, then by editor count descending, then reader count descending.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Sharing & Visibility Summary

Tier 2 — audit-critical (in the Audit Pack by default). Describes the org’s potential record-visibility paths via two tables: object Org-Wide Defaults (OWD) and the role hierarchy. OWD is the baseline record-access setting Salesforce applies to each object before sharing rules widen it (Private, Public Read Only, Public Read/Write, Controlled By Parent). This report describes potential visibility, not a per-user record count (that would require sharing recalculation, which is out of scope).

Note — Sharing rules ARE enumerated. Sharing rules ship: the Sharing Rules column carries the real count per object and Broadens To lists the distinct access levels those rules grant. If enumeration is unavailable on a run, the column falls back to n/a (not enumerated) for that object — which is explicitly not a claim that the object has no sharing rules. A 0 is a measured zero; n/a (not enumerated) is not.

Primary table — Object OWD & Rules

Column Meaning
Object Object API name.
Label Object label.
Internal OWD Internal org-wide default, mapped to a readable label: Private, Public Read Only, Public Read/Write, Controlled By Parent, or Public Read/Write/Transfer.
External OWD The external org-wide default, same mapping.
Sharing Rules Count of criteria- and owner-based sharing rules enumerated on the object, or n/a (not enumerated) when enumeration was unavailable for it.
Broadens To The distinct access levels those rules grant (e.g. Edit, Read), sorted; an em dash when the object has rules enumerated but none; blank when not enumerated.
Has PII Fields Whether any in-scope field on the object is flagged PII/sensitive.
Severity OWD risk posture (see below).
Notes Public Read/Write exposes records org-wide when the OWD is public write; otherwise blank.

Severity logic (exact)

This mirrors the OWD severity in Data Security Posture. Only critical/high rows count toward the flagged total — a MEDIUM sprawl row is surfaced but not flagged. Primary rows sort by severity descending, then object name ascending.

Secondary table — Role Hierarchy

Column Meaning
Role Role name.
Developer Name Role developer (API) name.
Parent Role Parent role name (em dash if the role is a root).
Depth Distance from the root (root = 0). Cycle-guarded, so a malformed hierarchy never loops.
Direct Children Number of roles directly beneath this role.
Total Subordinates Total descendant roles (all levels), cycle-safe.

Role rows sort by depth ascending, then developer name ascending. Roles do not carry a severity column.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Change History (Setup Audit Trail)

Tier 2 — audit-critical (in the Audit Pack by default). One row per configuration change — who changed what, when — sourced from Salesforce’s queryable SetupAuditTrail. The differentiator is retention: Salesforce natively keeps only ~180 days of audit trail, so this report accumulates history beyond that window into MetaSync’s own store, growing an audit archive over time.

Retention windows (exact)

Data source

SetupAuditTrail only — the configuration-change log, never business data. Read-only.

Columns

Column Meaning
Timestamp When the change was made (CreatedDate).
Actor Username Username of who made the change (known for rows seen in the current pull; retained-only rows fall back to the actor name, then an em dash).
Actor Name Display name of who made the change (em dash if unknown).
Acting As The DelegateUser — i.e. someone acting as / logged in as another user. Flagged for audit; blank when not a delegated action.
Category Governance bucket assigned by keyword (see below).
Section The Setup section that changed (em dash if none).
Action The specific setup action recorded (em dash if none).
Description Salesforce’s human-readable change description (Display).
Severity Change risk (see below).

Category buckets

Each entry is bucketed by substring-matching its Section + Action (lowercased); the first matching rule wins:

Severity logic (exact)

Severity is a separate substring check on Action + Section (lowercased):

Note. This report never produces critical rows. Only high rows count toward the flagged total. Rows are newest-first. The Notes state the captured span (earliest → latest date and day count) versus Salesforce’s ~180-day native retention.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Org Licenses & Storage

Tier 3 — capacity report, opt-in (NOT in the Audit Pack by default). Available vs used licenses and data/file storage headroom — the org’s capacity at the moment the snapshot was built. It answers: are we about to run out of licenses or storage, and what are we paying for but not using? Useful for renewal planning, de-provisioning evidence (pair it with Inactive Users with Active Access) and audit statements like “at the time of review, data storage was at 62%”.

Warning — Point-in-time, by design. This is OPERATIONAL data, not metadata — it changes continuously as the org operates, with no admin action. Every figure is a reading taken when the governance snapshot was built; rebuild the snapshot to refresh. For the same reason the report is deliberately excluded from Change Impact analysis and drift alerts — day-to-day utilization movement never generates change noise.

Primary table — Licenses

Column Meaning
Kind User License or Permission Set License.
License The license label (e.g. Salesforce, Salesforce Platform).
API Name The license API name (Name / DeveloperName).
Status The Salesforce license status (Active, Disabled, …).
Used Licenses currently assigned.
Total Licenses provisioned, or Unlimited (Salesforce reports a negative total for unlimited types).
Remaining Total − Used (an em dash for unlimited types).
Utilization Used ÷ Total as a whole percentage (an em dash for unlimited types).
Expires Expiration date — permission set licenses only (blank for user licenses).
Severity Capacity risk (see below).
Notes Plain-language flag, e.g. Fully consumed — no headroom to provision the next user.

Secondary table — Org Storage

Column Meaning
Storage Data storage or File storage.
Used (MB) / Max (MB) / Remaining (MB) From /limits: Used = Max − Remaining. Remaining can go negative when the org exceeds its limit.
Utilization Used ÷ Max as a whole percentage (can exceed 100%).
Severity / Notes Storage risk band and its plain-language flag (see below).

Severity logic (exact)

License rows sort by severity, then utilization (worst first). Both storage rows and license rows count toward the flagged total. License types with zero provisioned and zero used licenses are omitted (unprovisioned SKUs every org carries) — the Notes state how many were dropped.

Note — Degraded modes. A failed PermissionSetLicense query drops that section (the table lists user licenses only) and a failed /limits call (it requires the View Setup and Configuration permission) empties the Org Storage table — each with an explicit note, never silently. Only a failed UserLicense query marks the whole report unavailable.

When this report exists in the latest snapshot, a Licenses & storage section (storage gauges + the busiest user licenses) also appears on the Data Security Posture page in Confluence on the next sync. See Data Security & Classification.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Orphaned / Unused Config

Tier 3 — hygiene report, opt-in (NOT in the Audit Pack by default). A curated review list of configuration that looks unused. Every row is a candidate for cleanup, never a delete instruction — the severity ceiling is deliberately low. It answers: what config can I probably retire?

The three categories

Columns

Column Meaning
Category Inactive Flow, Unused Permission Set, or Unreferenced Custom Field.
Component Type Flow, PermissionSet, or CustomField.
Component Name The flow label, permission set name, or field API name.
Parent Object Object the custom field belongs to (blank for flows and permission sets).
Status Why it is a candidate (see per-category status text above).
Last Modified Last-modified timestamp where available (blank for unreferenced fields).
Inbound References Inbound dependency / active-assignee count (0 for unreferenced fields; blank for inactive flows).
Severity LOW throughout, except MEDIUM for unreferenced PII fields.
Recommendation Always review candidate — verify before deletion.
Notes For PII fields: PII/sensitive field — unreferenced data is a minimisation concern.

Warning — Not a safe-to-delete list. MetadataComponentDependency does not capture every reference type (dynamic references, some formula/Apex, managed packages, dashboards). A field showing “no dependencies” is a candidate for review, NOT safe to delete — always verify first. If the dependency API is unavailable, the unreferenced-field category is skipped gracefully and a note explains the gap.

Because severity is capped low (never critical/high), the flagged total is effectively always 0 — this report surfaces candidates, not risks.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Documentation Coverage

Tier 3 — hygiene report, opt-in (NOT in the Audit Pack by default). Scores how well the org’s objects and fields are documented (field Description / Help Text, object Description) and how much of the classified-PII surface actually carries a classification. It answers: is our metadata self-explanatory to auditors and new admins, and where are the gaps? Reuses MetaSync’s Data Dictionary index as the field universe — it does not re-query field docs. See PII & data classification.

Primary table — per-object scorecard

Column Meaning
Object Object API name.
Label Object label.
Fields Customizable field count (the per-object denominator).
Description % Percentage of the object’s fields that have a Description.
Help Text % Percentage of fields that have Help Text.
Object Described Whether the object itself has a Description.
Detected-Sensitive Classified % Of the object’s fields that MetaSync detected as sensitive, the percentage that carry a classification (PII flag, SF SecurityClassification, or ComplianceGroup). Note the denominator: it is the detected-sensitive fields, not all of the object’s fields — an object with one detected field, classified, scores 100%.
Readability Score Per-object score 0-100 (formula below).
Coverage (severity) Coverage severity derived from the readability score (see below).

Scores & severity (exact)

Per-object readability score = round(100 × (0.5 × Description% + 0.3 × HelpText% + 0.2 × object-described)), where each ratio is 0-1.

Coverage severity (lower coverage is worse, so worst-documented objects carry the highest severity):

There is also an org-level headline coverage score reported in the Notes: round(100 × (0.35 × pct fields with Description + 0.25 × pct fields with Help Text + 0.20 × pct objects with Description + 0.20 × pct detected-sensitive fields classified)), each pct a 0-1 ratio across the whole org. Primary rows sort by readability score ascending (worst first). Only high rows count toward the flagged total.

Note — The classification term uses the detected-sensitive denominator. The fourth term divides by the fields MetaSync’s detector flagged as sensitive, not by all fields — the same denominator as the Detected-Sensitive Classified % column above. And when the detector finds nothing sensitive, that term scores a full 1.0 rather than 0: an org with nothing to classify carries no classification debt. Substituting an all-fields “PII classified” percentage will not reproduce the headline score.

Warning — Two different scores share the name “Documentation Coverage”. This report’s headline score and the Documentation Coverage page MetaSync publishes to Confluence are computed from different formulas, so the same org legitimately shows two numbers, and they can differ widely. (Earlier revisions of this note quoted a specific org’s two scores as an illustration; those figures went stale the moment either input moved, so the note no longer pins live numbers into static documentation.) This report weights 0.35 / 0.25 / 0.20 / 0.20 across description, help text, object description and classification; the Confluence page weights 0.5 / 0.25 / 0.25 over its own inputs. Neither is wrong, but they are not interchangeable — quote the one whose formula you mean, and don’t reconcile them.

Note. Some standard fields do not expose an editable Description / Help Text, so 100% field coverage is not always attainable on objects with many standard fields.

Secondary table — To-Document Checklist

Column Meaning
Object Object API name.
Field Field API name.
Missing Both, Description, or HelpText — what the field is missing.
Data Type Field data type.
PII / Classified Whether the field carries a classification.

The checklist lists every field missing a Description and/or Help Text, sorted PII-first, then most-actionable missing type first (Both, then Description, then HelpText), then object/field name.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

Installed / Managed Packages

Tier 3 — inventory report, opt-in (NOT in the Audit Pack by default). The packages Salesforce reports through InstalledSubscriberPackage: one row per package with its name, namespace, installed version, and whether it is managed and/or a beta build. Treat it as what that query returns rather than as a guaranteed-complete inventory — an org can run code under a namespace this query does not list, and MetaSync surfaces such namespaces elsewhere (component pages and the Permission Sets index show the namespace each component carries). It answers: what third-party and managed code is running in this org, and at which versions? — the starting point for a supply-chain / third-party-risk review and for spotting beta packages left in a production org.

Column Meaning
Package Name The subscriber package’s display name (SubscriberPackage.Name).
Namespace The package namespace prefix, or (no namespace) for unmanaged/namespace-less packages.
Version Installed version, assembled Major.Minor.Patch (with .Build when present).
Managed Whether the installed version is a managed-package release (SubscriberPackageVersion.IsManaged).
Beta Whether the installed version is a beta build — the only condition that raises severity.
Notes Plain-language flag, e.g. Beta package; blank for a normal managed/unmanaged package.

Rows sort by severity (beta packages first), then package name. Publisher / vendor is deliberately not shown — it is not exposed by the InstalledSubscriberPackage / SubscriberPackage objects, so the report never guesses it.

Note — Degraded mode. If the Tooling InstalledSubscriberPackage query fails (the integration user needs API access), the report returns an empty table with an explicit note — never silently, and never as a claim that the org has no packages. An org that genuinely has none says so in its own note.

Snapshots, Excel & CSV

This report is not computed on demand — it is read from the latest governance snapshot. Building the governance suite runs every report once into a single snapshot keyed gov-{timestamp} (the millisecond time of the build). A new build becomes the current snapshot and every report in it shares the same identity and timestamp — one coherent moment in time. Earlier snapshots are not discarded immediately: MetaSync retains the 3 most recent prior builds so a snapshot can be compared against its predecessors, and evicts beyond that. Reports always read the current snapshot. See Governance.

User Access Matrix

The User Access Matrix produces a per-user effective-access report: for each user, their object-level CRUD (OLS — Object-Level Security: Create/Read/Update/Delete plus the View All / Modify All record overrides) and their field-level read/edit (FLS — Field-Level Security). It is the user-centric counterpart to the field-centric Field-Level Security / PII Access and the source engine both share. See Profiles and Permission Sets.

How “effective” access is computed

Scope options

Grant Origin values

Every access cell is tagged with a Grant Origin, which drives the Excel colour fill (blue/green/amber/red/orange/grey) and the CSV text:

Grant Origin Meaning
Profile Granted by the user’s profile only (light blue).
Permission Set Granted by permission set(s) only (light green).
Combination A profile AND at least one permission set both contribute (light amber).
Modify All Data Org-wide Modify All Data override — full CRUD everywhere (light red; labelled with a ⚠ in Excel).
View All Data Org-wide View All Data override — read everywhere (light orange; ⚠ in Excel).
None / — No access (grey).

Excel workbook — four sheets

Each user’s .xlsx has these sheets (header rows are bold and frozen; Object Access and Field Access carry an autofilter):

Sheet — Column Meaning
Summary (key/value) Username, Full name, Active, Last login, Profile, Permission sets, Role, Record visibility, plus counts (Objects with access, Elevated objects (ViewAll/ModifyAll), Fields editable), FLS scope line, an optional Note, an optional ⚠ Modify/View All Data banner, and any user Notes.
Object Access (OLS) — Object Object API name.
Object Access — C / R / U / D Create / Read / Update / Delete (check mark = granted; the four cells + ViewAll/ModifyAll are colour-filled by Grant Origin).
Object Access — ViewAll / ModifyAll The record-scope overrides that bypass sharing.
Object Access — Grant Origin The origin category (see table above).
Object Access — Sources The contributing profile / permission set names.
Object Access — Notes Cell notes (e.g. muting applied, muting unresolved, system permissions not measured for N source(s)).
Field Access (FLS) — Object / Field The field’s object and API name.
Field Access — Effective Read / Effective Edit Access after OLS gating (coloured by origin; grey when raw access is gated off by object access).
Field Access — Raw Read / Raw Edit Ungated FLS, for transparency.
Field Access — Grant Origin / Sources / Notes Origin category, contributing sources, and per-cell notes.
Legend Explains every Grant Origin colour, plus Record visibility (a separate Role+sharing axis, never folded into CRUD/FLS), FLS gating, FLS scope, and Muting.

CSV differences

Note — Record visibility is a separate axis. Role + sharing determine which records a user sees; this is reported as the Record Visibility Scope column/label only and is NEVER folded into CRUD or FLS. (View All / Modify All do bypass sharing, which is why they live on the object axis.)

Snapshots & download all

Access snapshots are keyed snap-{timestamp} and overwrite the prior one. “Download all” builds a ZIP of one file per user plus a top-level _manifest.csv (username, profile, elevated, flsScope, file) — chosen over a single mega-workbook so it scales to any org and individual files can be handed to a reviewer without exposing everyone. The Audit Pack nests this same ZIP under access-review/.

Audit Pack

The Audit Pack bundles the auditor-relevant reports into a single ZIP so you answer an audit request with one download instead of running ten exports. It assembles in the background from already-persisted snapshots — the export itself never recomputes anything, so its contents are exactly as fresh as the snapshot you last built. Every governance report file in it shares the same snapshot id and timestamp, and since the snapshot build now rebuilds the Access Review matrix as its first step, the nested per-user ZIP shares that moment too. The one exception is a retained (older) snapshot, where the two genuinely differ — and the pack’s _README.txt states both timestamps explicitly. See Governance.

Warning — One moment — unless the Access Review is bundled. The Access Review matrix is stored per site, not per governance snapshot, so a pack that nests it holds two moments. When that happens the README says so, prints the access snapshot’s own timestamp beside the governance one, and drops the “one coherent moment” line rather than asserting something untrue. Compare the two dates before treating joiner/leaver activity between them as evidence. A pack without the Access Review keeps the single-moment guarantee.

What it bundles by default

The default (audit-critical) contents are the eight Tier 1-2 reports, all marked auditDefault in the report registry:

The Tier 3 reports — Org Licenses & Storage, Installed / Managed Packages, Orphaned / Unused Config and Documentation Coverage — are opt-in and not bundled by default. The User Access Matrix is pre-selected in the build modal alongside the eight above, and is handled specially: when requested, its per-user “download all” ZIP is built from the access snapshot and nested under access-review/.

Format selection

One format for the whole pack: all-xlsx (each report as a colour-coded workbook) or all-csv (each report as an RFC-4180 CSV). The chosen format is stamped in the README.

ZIP layout

Entry Contents
<reportKey>_<orgAlias>_<date>.<xlsx\|csv> One file per included governance report (e.g. elevated-access_AcmeOrg_2026-07-02.xlsx).
access-review/access_report_<orgAlias>_<date>.zip The nested per-user Access Review ZIP, only when the User Access Matrix is included and a snapshot exists.
_README.txt Plain-text cover sheet (see below).
_summary.xlsx A spreadsheet index mirroring the README: one row per report with its file name, row count and flagged count.

The _README.txt

When reports are omitted (and how it’s disclosed)

A requested report is omitted — never silently dropped — when it is missing from the current snapshot, was marked unavailable at build time (its build failed, with the reason carried forward), or its data can’t be found in the snapshot. For the Access Review specifically, it is omitted with no Access Review snapshot — build it first when no access snapshot exists. Every omission is listed by title and reason in both _README.txt and _summary.xlsx.

Warning — Build the snapshots first. The Audit Pack reads persisted snapshots and never recomputes. If no governance snapshot exists it fails with “No governance snapshot — build it first.” Build the governance suite (and the Access Review, if you want it bundled) before requesting the pack.