Sales Operations System
A record of who changed which field on a record, and when.
Disputes about what an opportunity was worth, when it moved, or who reassigned it are settled by a change history and by nothing else. The bar is deliberately specific because vendors routinely present a security or login log as an audit trail, and those answer a different question entirely.
A log of sign-ins tells you who was in the building. It does not tell you who changed the number.
Yes where the platform records which field changed on a record, the user who changed it, and when.
Partial where a change history exists but the documentation does not establish all three - commonly a per-record log that names the event and the time but not the acting user, or not the field.
No where the only log is a feed of interactions and system events rather than field changes.
A security or sign-in log is excluded regardless of what the vendor calls it. It records who was in the system, not what they changed.
No vendor documentation reachable during this evaluation describes a field-level change history recording who changed which field on a record and when. The security and privacy paper covers access controls, encryption and backups but does not mention change logging.
No vendor documentation was found describing a log of which user changed which field on a record and when. The deal record documents time in current stage, and reporting exposes a status change date, but neither attributes a change to a user or records the previous value. This is recorded as an absence that the vendor should confirm rather than a documented absence.
The vendor states that every change to data in the system is captured automatically in the news feed, recording the user who performed the action, the time, and the old and new values where something was changed. That meets the bar of who changed which field on a record and when. Separately, the master layout keeps its own revision history for layout changes, and a Sales Stage History report records stage transitions with dates.
Right-clicking an attribute value and choosing View edit history returns a log of updates made to that attribute including who or what updated it, so the actor and the field are both captured. A record's Activity tab separately shows a timeline of updates including attribute updates, list changes, notes and meetings. Vendor documentation does not state that the edit history displays a timestamp or the previous and new values, does not give a retention period, and describes no account-wide or exportable change log across records, so the capability is present but only partly evidenced against the bar.
Bigin has an audit log, described as listing all actions performed in the account chronologically in a single window, retained for three years and filterable by entity, user, action and time range, with CSV export of the full three years unfiltered or 180 days filtered. That is more than a login log, and it ties an action to a user, an entity and a time. What the vendor does not state is whether an entry names the field that changed and its previous and new values, which is the bar here, and no separate record level change history article exists.
A Lead Activity section on the lead profile logs interactions such as emails sent, replies received, LinkedIn interactions, notes added and tasks completed, and records when a lead was added to a pipeline. That is an interaction log, not a field change history: no vendor documentation states that a change to a field is recorded with the previous value, the new value and the user who made it. Activity logs cannot be exported, which the vendor confirms directly. A separate view of team members' activity is documented as not generally available, and its contents are not described.
https://developer.breakcold.com/help/contacts-lists/where-can-i-view-all-lead-activity
https://developer.breakcold.com/help/tasks-activities/how-is-activity-tracked-in-breakcold
https://developer.breakcold.com/help/imports-files/can-i-export-activity-logs
https://developer.breakcold.com/help/workspace-permissions/can-i-see-team-members-activity
The only change-tracking surface named in vendor documentation is a Recent Logins tab that lets a super administrator monitor log-in activity on the account, which is a security log and not an audit trail. No vendor support article describes a record history showing which user changed which field, when, and from what value to what. The security marketing page asserts that every action is logged, but no documentation explains what a customer can see or where.
The Event Log, opened from Settings under Organisation or from a lead, shows every change made in the organisation, who made it and how it happened, covering changes from users, Workflows, integrations and the API, and can be filtered by date, lead, event type, action and user. The underlying event records name the acting user, list the changed fields, and carry both the previous and the current values with timestamps. It is also exposed through an API and through webhooks. The constraint is retention: the log covers the last thirty days only.
The Activity Log is the documented record history, and vendor documentation describes its contents as logged activities, tasks, internal notes, synced emails, integration interactions and calendar events. It does not describe capturing which user changed which field on a record and when. No separate change log, field history or audit log feature is documented, and the data privacy and security article covers authentication and hosting without mentioning an audit log.
No vendor documentation describes a per-record change history showing who changed which field and when. Records carry created-at and created-by metadata only, and the data model, permissions and integration articles are silent on change tracking. The security page mentions that audit logs can be supplied as part of an enterprise security review, alongside compliance reports and data processing agreements, and separately states that logs are retained for up to ninety days; both readings point at infrastructure and security logging rather than a user-facing record change trail, so the distinction needs vendor confirmation.
Field Edit History meets the bar of who changed which field on a record and when: it records the field name, the previous and current value, the date and time, the user, and the source of the change including manual edits, imports, workflows, APIs and integrations, and it covers deals as well as contacts and accounts. It is constrained rather than complete: an admin must nominate the tracked fields, up to 50 per module, and history is retained for six months only. The separate Audit Logs feature covers configuration changes such as workflows, sequences, territories and settings, not record data, and is retained for 90 days.
Each record carries a property history showing which property changed, the previous and new values, the change source including the user responsible, and the date and time. History can be viewed per property or across all properties on the record, filtered by property or source, and exported.
Field History Tracking logs which user changed a tracked field on a record, when, and the previous and new values, across standard and custom objects, with two reports in Advanced Reporting exposing the change log. Formula, auto-number, expected revenue, binary and over-length fields cannot be tracked, and history is retained for a fixed period.
The contact record carries an activity feed of events related to that contact, but no vendor documentation found states that it records which user changed which field to which value and when, and no account-wide change log is documented.
Dataverse auditing records who created or updated a record, when, which columns changed and the previous value. It is switched on at environment level and then enabled per table and per column, and change history is read on the record itself under Related, then Audit History, or across records in the Audit Summary view, gated by the View Audit History and View Audit Summary privileges.
The Activity Log records when a change was made, who made it, the item or group it was made on, the column it was made on, and the previous value against the new value - which meets the bar of who changed which field on which record and when. Retention is capped, and the documented cap ranges from one week to five years.
The Change Log records a contact record's history from creation to permanent deletion, capturing who created and modified the record, which fields changed with their old and new values, the date and time, and lifecycle events such as merges and deletions. Deals carry an equivalent History tab listing changes by date and time across owner, description, amount, expected close date and custom fields.
An audit log records user name, date and time, type of action, number of edits, session details, status, device type and IP address, covering events such as logins, bulk edits and list exports, and cannot be exported. Vendor documentation does not state that it identifies which field on which record was changed, or the previous and new values, so the "which field" half of the bar is not evidenced.
A Changelog tab under History on an item's detail view lists changes made to that record since creation, sorted by date and time, covering stage, value, label, contact, expected close date and both default and custom fields. Vendor documentation does not state that the changelog attributes each change to a named user, so the "who" half of the bar is not evidenced. Separately, a security dashboard audit log records security-related changes across the account and is documented as retaining two months of history; that log is not a record-change trail.
A Show History control in the Created section of a record's details page opens an audit history for that record. The vendor describes the captured event types as record creation, deletion, cascade deletion of child records, merging and quote status changes, and states that further event types would be added over time. Documentation does not state that the log records changes to individual fields, nor that it attributes each entry to a named user, so the stated bar of who changed which field and when is not evidenced.
Field History Tracking records the date, time, nature of the change and the user who made it, including old and new values, for fields selected per object. Retention is up to 18 months in the application and 24 months via the API unless Field Audit Trail is enabled, which retains until manually deleted. Events and tasks are capped at six tracked fields each. This clears the bar of who changed which field on a record and when; the separate Setup Audit Trail logs administrative changes only.
Each pipeline has a newsfeed listing changes, with documented event types including new box, edit stage, assign to, add contact, add comment, add file, add task, edit task due date, edit task status and delete box. The pipeline view shows the last fifty changes and the whole newsfeed can be exported to give the pipeline's history from creation. Vendor documentation does not state that entries name the acting user, nor that they record the previous and new value of a changed field, so the "who changed which field" half of the bar is not evidenced.
No vendor page reachable to this evaluation states that Vtiger records which field on which record was changed, by whom and when. A deal's summary view carries an Updates section alongside touchpoints and comments, but what the Updates section contains is not documented on the pages reviewed, so it cannot be treated as evidence either way.
The audit log is a chronological record of the actions each user performs, covering record creation, editing, deletion and imports as well as setup changes. It can be filtered by module, user, action type and period, exported to CSV, and is retained for three years. Separately, each record detail page carries a Timeline showing changes and interactions with the user responsible, the time and the source of the change, also retained for three years. Neither the audit log documentation nor the Timeline documentation states that the specific field changed and its previous and new values are recorded, so the "which field" half of the bar is not evidenced.