Every system keeps its own audit log, in its own shape, for its own retention period. A question like who gave that contractor access to the plant room, and who changed the chiller setpoint the same week, means separate logins and separate export formats. Audit Trail reads the audit logs as they are written: the Okta System Log and Microsoft Entra directory audits, the audit logs of your access platform, and the audits your building platform records against each object.
It matches each change to a change request or work order where one exists. At the end of the period it proposes a report by system, actor and object, and a follow-up ticket for each change that no request explains. The retained copy lands in your warehouse.
This is a reference listing. It documents what Fibric would read from Audit Trail and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.
Inputs
Okta System Log events with actor, target, event type, outcome and published time, read by time bounds or polled
Microsoft Entra directory audits: activity, category, initiated-by, target resources and result
Access platform audit logs, such as Verkada Get Audit Logs with user, IP address, event and device, or Brivo Audit Events
Building platform audits with user identity, action type and pre and post values, from the Metasys audits and activities endpoints
Change requests and work orders in ServiceNow or Jira Service Management, to explain a change
Prior period reports and open follow-ups in your warehouse, such as BigQuery, to carry unanswered items forward
Proposed actions
Target capability: propose the period report, changes by system, actor and object with the request that explains each one, for the security lead to approve
Target capability: propose a follow-up ticket in ServiceNow or Jira Service Management for each change with no matching request
Target capability: propose an export of the period's matched log to BigQuery or Snowflake, so retention outlasts each source system's own
Target capability: propose a same-day Teams or Slack notice for changes to objects you mark sensitive, such as a plant room access level
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Explain every access level change this month
Verkada audit log entries that add a user to an access group are matched to Jira Service Management requests. Those with no request become follow-up tickets for the security lead.
A Metasys audit shows a chiller setpoint written by a named user. The operator finds the ServiceNow change request for that night and lists the change as explained in the report.
Okta System Log and Entra directory audits for the period are exported to BigQuery once the report is approved, so a question next year can still be answered.
An identity connector with audit access, such as Okta with the System Log API or Microsoft Entra ID with directory audit permissions
An access control connector that serves an audit log, such as Verkada or Brivo
A building platform connector that serves audits, such as Johnson Metasys, or Desigo CC where its log is exposed
A change or ticket connector for requests and follow-ups, such as ServiceNow or Jira Service Management
A warehouse connector for the retained copy, such as BigQuery, Snowflake, or PostgreSQL
Authentication
Audit Trail authenticates to no system itself. It reads each audit log through the connector you have connected for that system, and every report, ticket and export is a proposal until a person approves it.
Limits
Each source keeps its own retention. An Okta System Log query defaults to seven days before its upper bound; older history is read in slices.
A change is explained only by a request the operator can find. Changes agreed verbally show as unexplained until a person adds the reason.
Systems with no audit API, or with audits held only in a local database, are out of scope until a connector exposes them.
The operator reads audit logs. It never edits them, and it never reverses a change it finds.
Access and pricing
Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.
The security lead or compliance owner you name. They see every change, the request that explains it or the note that none does, and the proposed follow-ups. They can add an explanation, drop a follow-up with a reason, or approve as is.
Can it undo a change it finds?
No. It reads audit logs and proposes reports, tickets and exports. Reversing a change is a separate action a person takes in that system, with its own audit entry.
What proves the report itself was not altered?
Each approved report is stored with the source log entries it was built from, the time bounds used, who approved it, and the export written to the warehouse. Regenerating the same period from the same sources produces the same report.
Ask about Audit Trail
Ask about the capabilities and requirements in this listing.
This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy