ConceptReviewed 2026-09-29

Audit trail and record history

What an audit entry records (who changed what, when, from where, with before and after values), how entries group into a record's history and a project's history, and who may read them.

Audit trail and record history

An audit entry is one line in the organization's permanent change log. It says who did something, when, from which address, and exactly what changed. Entries are written for every record that is created, changed or deleted, and for sign-ins (including refused ones), sign-outs and file downloads. Nobody can edit or remove an entry.

How it works in NirmaanOne

What one entry holds

  • Who: the person, shown as a name or email, with the IP address and browser. The actor kind is User, AI Connector (a user acting through a connected assistant, shown as "<name> via AI connector"), Workflow (a workflow rule acting on somebody's behalf, "Workflow (as <name>)") or System.
  • When: the moment of the save.
  • Action: Create, Update, Delete, Sign In, Sign In Failed, Sign Out or Download.
  • Record: the kind and name of the record (for example "Booking · BK-2026-27-00042"), and the record it belongs to when it is a line of something larger ("of <parent>").
  • What changed: for an update, a table of Field / Before / After; for a create or delete, every value ("Value" or "Value when deleted"). Very long values are cut at 4,000 characters.
  • Request: one save in the app can write many rows (a demand run drafts many demands, each with lines). Every row written by the same save shares one request id, and Everything saved with it in the entry panel filters the log down to exactly those rows.

What is never shown

Passwords, authenticator secrets, backup codes, app secrets and unsubscribe links are recorded as changed but their value reads "[redacted]". The created / updated stamps on every record are not listed, because the entry itself already says who and when. A few columns that change as a side effect of use rather than by anyone's decision are ignored too: a user's last sign-in time, a workflow rule's run times, a campaign's sent / failed / skipped counters, and the token plumbing of an AI connection.

Tables that are logs themselves are not audited: notifications, workflow runs, the message outbox, campaign recipient rows, the period-balance cache, connection call logs and the global permission catalogue.

Entries are written with the save

An entry is written in the same transaction as the change. A save that fails leaves no entry; a save that succeeds always has one. Changes are recorded from 28 September 2026; older records show "No history yet" until something changes on them.

One record's history

The History button on a record page (tooltip "Who changed this record, what and when") opens "History · <record>", newest first, 25 at a time with Load older changes. It includes the record's own lines: a booking's parties, an offer's items and payments, a role's permissions, a user's role assignments. A line's parent is the record it hangs off (a unit's is its floor, a role permission's is its role), which is how the panel knows what to include.

A project's history is wider: every entry that belongs to that project is included, whether it came from a unit, a parking slot, a pricing plan, a construction stage, an offer, an estimate, a booking, a demand, a receipt or a voucher of that project. Downloads from a project's screens are attributed to the project too.

Who may read it

  • One record's History: anyone with the View permission on that record's module (a bookings user sees a booking's history), or anyone with the View permission on Audit Trail.
  • The organization-wide Audit log and the Open in the audit log link in the panel: only the View permission on Audit Trail. By default that is the Administrator, Compliance Officer and Auditor, because the log shows every user's sign-ins and changes.

Date filters on the log are read in the organization's time zone (India Standard Time).

Example

On 29 September 2026 at 11:42 Rohan Desai, a Sales Manager, extends the validity of estimate EST-00318 from 5 October to 12 October so the buyer can arrange finance. The estimate's History now shows, at the top:

Action Update
Summary "Changed valid until"
Who Rohan Desai · 29 Sep 2026 11:42 · 103.21.58.14
Field / Before / After Valid until · 2026-10-05 · 2026-10-12

The same save also wrote a system activity "Estimate Validity Extended" on the opportunity. It is not a line of the estimate, so it does not appear in the estimate's history, but the Audit log's Everything saved with it on the entry shows both rows side by side, because they share one request.

Two days later a workflow rule reassigns the opportunity to Priya Shah after Rohan's leave starts. That entry's actor reads "Workflow (as Rohan Desai)" so nobody mistakes it for a change Rohan typed. When Priya later logs a site visit through her connected assistant, the entry reads "Priya Shah via AI connector".

Where you see it

  • History panel: the History button on bookings, units, opportunities, estimates, contacts, tenants, societies, payments, commissions, companies, projects, users, demands, roles and vouchers.
  • Audit log: the whole organization, with filters by record kind, action, actor kind, user and dates, and the entry panel with Everything saved with it.
  • Project overview: the project's History takes in everything that belongs to the project.
  • Users and Edit role: sign-ins, role changes and permission changes.
  • Generated documents and Importing and exporting Excel sheets: every download is a Download entry.

Related

  • Audit logScreen

    The organization-wide change log: every create, change and delete, every sign-in (including refused ones), sign-out and downloaded file, with who did it, when, from where and what changed.

  • History panelScreen

    See who changed a record, what they changed and when, including the record's lines, newest first, and jump to the full audit log.

  • Roles & PermissionsScreen

    The list of your organization's roles: open one, create or clone a role, deactivate or reactivate it, and delete custom roles nobody holds.

  • UsersScreen

    The people in your organization: invite new users, change their role, deactivate or reactivate them, reset a lost two-factor authentication, and resend or revoke pending invitations.

  • Edit roleScreen

    Change a role's name, description, active flag and permissions, see who holds it, and open its History.

  • Project overviewScreen

    A project's home page: its details, site, land, RERA registration, inventory summary, whether it is ready to sell and collect, where its money stands across its RERA accounts, and the setup checklist.

  • Generated documentsScreen

    The organization-wide log of every document generated from a template or uploaded against a record, where you preview, download, email, void or delete them.

  • Importing and exporting Excel sheetsScreen

    Download a project's units, parking slots, construction stages or unit pricing as an Excel sheet, fill in the template, check it row by row and import it in one go.

  • Roles and permissionsConcept

    What a permission is (a module plus an action), how roles bundle permissions, the twelve default roles and what each is meant for, the one-role-per-user rule, and when a change reaches a signed-in user.

  • AI connectorsConcept

    How an AI assistant such as Claude or ChatGPT connects to NirmaanOne, acts as one user within that user's role, what it can and cannot do, and how connections are watched and stopped.

  • User accounts: invitations, status and sign-inConcept

    How a person gets an account (by invitation), the four user statuses and how they are derived, how long an invitation link lives, what happens at sign-in with and without two-factor authentication, how long a session lasts, and what deactivation does.