Data Change Events: Overview and Setup
A Data Change event is a notification by the application of when a record or set of records are changed.
Data Change events enable sites to audit activity against the Archibus database.
Set Up Data Event Logging
See Set Up Data Event Logging (Archibus Administrator).
Uses
This feature has a number of uses.
Audits
Sites often have changes that require an audit trail. For instance, you may bill millions of dollars a year in indirect costs to the government by using charges proportional to the area occupied by government research grants. Alternately, you may bill indirect costs to healthcare insurance provider using a similar proportional-area scheme.
In either case, the numbers must track subtle details of occupancy – such as usage for short periods of time, usage split between departments, and employees that use multiple locations. Also in either case, the results are auditable back to six years, with any errors in the original billing subject to significant financial penalties. Having a complete audit log of who changed what value and when is a must.
Security
Secure sites wish to record every time an administrator makes a change to one of the security tables, such as the Archibus Users, Roles, Groups, or Process Assignments tables. In the case of a security breach, the site will review who had access to these tables and what changes they made.
Synchronizing Transactions
Within the Archibus business application activities, a transaction table is any table that records an important business-level event, such as the signing of a lease, a department claiming or releasing space, or the completion of a move. Archibus applications keep any important business transactions in transaction tables. The Ownership Transactions, Leases, Options, Room Percentage, Work Orders, Action Items, Move Orders, Recurring Costs, Scheduled Costs, and Cost tables have records for all significant business events, such as the purchase of a property, the expiration of a lease, the reassignment of a room, the approval of a capital project, etc. We can then determine costing, forecasts, and history from these transaction tables.
The business logic for each application activity takes the information in these transactional changes and then updates the associated inventory tables per the rules covered in the documentation. For instance, closing a move order (the record that holds the state of the move transaction) updates employee locations (the record that holds the current state of the inventory).