Settings logs
Settings logs is a level-0 source route whose client exposes no log mutation control. Mounting it immediately requests newest-first audit records, so it is not a safe read-only documentation surface.
Source declares /settings/logs for level 0; its Logs Audit → Settings logs sidebar entry additionally requires Enterprise plan state. The direct route does not repeat that plan gate and is not entitlement proof. None of this proves deployment, retention, or record availability.
Review the log table
Current client/API source can return or render:
- the author’s name and email;
- event type;
- configuration name/key;
- changed attribute names;
- new and old values, or added/removed values;
- date and time in the Dashboard display format; and
- the browser’s user-agent string.
Source defines page navigation but no search, filter, export, or general record-detail control. Its page-size callback is not established as a reliable workflow. No page or record was requested.
View schedule changes
For a source record whose changed attribute is schedule, See changes can open a New/Old weekly comparison. This label trace does not authorize reading a real schedule or actor.
Schedules, authors, timestamps, and changed configuration values are operational/audit data and remain excluded from documentation evidence.
Protect audit data
Settings logs can expose staff names and emails, browser/device information, configuration names and values, option lists, schedules, and other commercial or security-relevant details. Some protected settings are masked in normal settings reads, but do not assume every value shown through the logs is redacted.
- Use masked synthetic data for screenshots, training, and support examples.
- Share the minimum needed record with authorized people only.
- Do not paste user-agent strings, real setting values, account details, schedules, secrets, or employee information into chat, tickets, or public documentation.
What a log entry means
API source creates a configuration log when its configuration update path detects changed fields. The model can store configuration reference, author, event, changed data, user agent, and timestamps. A missing entry is not proof that no operational change occurred; source does not establish complete audit coverage.
No retention period, purge process, or export policy is verified in the current source. Follow your organization’s compliance and incident process rather than assuming that all records will remain available indefinitely.
Troubleshooting
Why can’t I find a filter or search box?
The fixed client source provides a newest-first list and page navigation, but no verified filtering or search controls. Runtime use remains blocked; re-entry requires an approved synthetic audit fixture and intercepted, immutable read receipts.
Why is a schedule shown as “See changes” instead of a value?
Schedules open in a comparison modal so their new and old weekly periods can be reviewed separately.
Why is a change missing from the table?
The reviewed implementation can log detected field changes for configuration updates. It does not prove complete coverage for every setting, operational action, or historical period. Source-only review cannot verify an underlying runtime configuration; any future comparison requires approved synthetic config/log fixtures and intercepted, immutable receipts.
Related guides: Language manager · Platform settings