vulkro-sf org field-audit-trail
Audits Field Audit Trail retention and PII history-tracking gaps
(SF-FIELD-AUDIT-001 / -002 / -003).
This is the "can you reconstruct what happened" audit. If a PII field has history tracking off, nobody can answer who changed it and when after the fact, and if the retention policy is short the history is gone before an audit asks for it.
Synopsis
vulkro-sf org field-audit-trail --target-org <alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | Target org alias or username, as known to sf org login. |
--format <fmt> | enum | table | Output format. |
--verbose, -v | flag | off | Bump stderr log verbosity. -v enables debug-level tracing for the vulkro + vulkro_sf targets; -vv enables trace. Honoured only when RUST_LOG is unset (an explicit RUST_LOG always wins). |
What gets read
FieldDefinition:EntityDefinition.QualifiedApiName,QualifiedApiName,IsHistoryTracked.FieldHistoryRetentionPolicy:DurableId,FullDataRetention,ArchivedDataRetention,ArchiveAfterMonths,ArchiveRetentionYears.
What gets reported
| Rule | Severity | What fires |
|---|---|---|
SF-FIELD-AUDIT-001 | High | A PII-shaped field with IsHistoryTracked = false. Signal org-field-history-pii-no-tracking. |
SF-FIELD-AUDIT-002 | Medium | A retention policy below the baseline: under 18 months of FullDataRetention, or under 10 years of ArchivedDataRetention. Fires per policy row. Signal org-field-history-retention-policy-short. |
SF-FIELD-AUDIT-003 | Low | Fires once when no retention policy rows exist at all, meaning the retention policy was never configured. Signal org-field-history-not-configured. |
The 18-month and 10-year thresholds are the Salesforce defaults, which are also what most regulated audits expect as the floor.
The PII shape filter is applied on the client because Salesforce does
not support a portable field-name match across entity definitions. It
uses the same PII lemma list as the SF-FIELD-PERM-001 rule, so the
Field Audit Trail audit stays semantically aligned with
org effective-perms.
Managed-namespace fields are skipped. A customer cannot toggle history tracking on a managed field from Setup, so flagging one would be pure noise.
Examples
vulkro-sf org field-audit-trail --target-org my-prod
vulkro-sf org field-audit-trail -o my-prod --format json > field-audit.json
Exit codes
0- no findings.1- posture findings reported.2- error.
These follow the org command-family contract printed by
vulkro-sf org --help.
Scope and honesty
The org is read locally through your own authenticated sf CLI login;
nothing is sent anywhere. The audit reads field definitions and
retention policy rows. It does not read field values, and it does
not read history records.
"PII-shaped" is a name-based heuristic: a field is judged by its API
name, not by inspecting its contents. That cuts both ways. A field
called Notes__c holding social security numbers will not be flagged,
and a field whose name merely resembles a PII lemma may be flagged when
it holds nothing sensitive.
Findings are static posture signals about audit-trail configuration, not a compliance certification. A clean run does not attest that an org meets any particular records-retention obligation.
Where to go next
- vulkro-sf org effective-perms - who can read and edit those PII fields.
- PII map - where PII lives across the org.
- Compliance mapping - how these signals map onto control frameworks.