Audit Trail
RAMP maintains a comprehensive audit trail across all entities — instances, templates, steps, and API access. Every state change, user action, and approval is recorded with the identity of the user who performed it, the exact timestamp, and a description of what changed. This audit data supports compliance requirements, post-incident review, and operational transparency.
What Is Logged
Section titled “What Is Logged”RAMP captures audit entries at multiple levels. The following sections describe what is tracked for each entity type.
Instance Audit Trail
Section titled “Instance Audit Trail”Every action on an instance is recorded in the InstanceAuditEntry table:
| Action | Description |
|---|---|
| Created | Instance was created from a template version |
| StatusChanged | Instance transitioned between statuses (Draft, Planned, Running, Paused, Completed, Cancelled) |
| VariableUpdated | Instance variable value was changed |
| TeamMemberAdded | A user or group was added to the instance team |
| TeamMemberRemoved | A user or group was removed from the instance team |
| RoleChanged | A team member’s role was changed (e.g., Executor to Deputy Head) |
| SettingOverridden | A step setting was overridden at the instance level (skippable, auto-complete, planned duration) |
| NoteUpdated | Instance note was created or modified |
| CommentAdded | Instance comment was added |
| Archived | Instance was archived |
Step Audit Trail
Section titled “Step Audit Trail”Step-level actions within instances are also recorded in the InstanceAuditEntry table with a StepId reference:
| Action | Description |
|---|---|
| StepStarted | Step was started |
| StepCompleted | Step was completed (includes completion result: Succeeded, OK with Complications, etc.) |
| StepPaused | Step was paused |
| StepResumed | Step was resumed |
| StepSkipped | Step was skipped (includes reason) |
| StepAborted | Step was aborted (includes reason) |
| StepCancelled | Step was cancelled (includes reason) |
| ForceComplete | Step was force-completed by Instance Head/Deputy (includes reason) |
| ForceSkip | Step was force-skipped (includes reason) |
| ForceAbort | Step was force-aborted (includes reason) |
| AttachmentUploaded | File was attached to the step |
| AttachmentDeleted | File attachment was removed from the step |
| ApprovalRequested | Step completion with “OK with Errors” triggered an approval request |
| ApprovalGranted | Instance Head approved a step result |
Template Audit Trail
Section titled “Template Audit Trail”Template-level actions are recorded in the TemplateAuditEntry table:
| Action | Description |
|---|---|
| Created | Template was created |
| VersionCreated | New template version was created |
| StatusChanged | Template version status changed (Draft, Published, Deprecated) |
| RoleAdded | Template role assignment was added (Owner, Editor, Viewer, Approver) |
| RoleRemoved | Template role assignment was removed |
| Deprecated | Template was deprecated |
| Undeprecated | Template was restored from deprecated status |
Step Design Audit Trail
Section titled “Step Design Audit Trail”Changes to template steps during design are tracked in the StepAuditEntry table:
| Change Type | Description |
|---|---|
| Created | Step was added to the template version |
| Modified | Step content, title, settings, or order was changed |
| Deleted | Step was removed (soft delete) |
| Reordered | Step position was changed within the hierarchy |
| Pasted | Step was pasted from another template version |
Step design audit entries include content snapshots — the old and new values for title, content, order, and parent step — making it possible to reconstruct the complete history of a step.
API Audit Trail
Section titled “API Audit Trail”All API requests are logged in the ApiAuditEntry table for security and compliance:
| Field | Description |
|---|---|
| Request path | The API endpoint that was called |
| HTTP method | GET, POST, PUT, DELETE, etc. |
| Status code | HTTP response code (200, 401, 403, 500, etc.) |
| Authentication method | JWT, Personal Access Token (PAT), Service Account, or Anonymous |
| User identity | Which user or service account made the request |
| Authorization result | Whether the request was authorized or rejected (403) |
| Duration | Request processing time in milliseconds |
| IP address | Origin IP of the request |
| Error message | For failed requests, the error details |
Audit Entry Structure
Section titled “Audit Entry Structure”Each audit entry follows a consistent structure regardless of the entity type.
Instance and Step Audit Entries
Section titled “Instance and Step Audit Entries”| Field | Description |
|---|---|
| Id | Unique identifier for the audit entry |
| Timestamp | Exact date and time the action occurred (UTC) |
| User | The user who performed the action |
| Action | The type of action (e.g., StatusChanged, StepCompleted) |
| Old Value | JSON representation of the previous state |
| New Value | JSON representation of the new state |
| Details | Human-readable description of what happened |
| Step ID | For step-level actions, identifies which step was affected |
Execution Log Entries
Section titled “Execution Log Entries”The execution log (used in the execution view) has a slightly different structure focused on real-time communication:
| Field | Description |
|---|---|
| Timestamp | When the entry was created |
| User | Who performed the action or posted the comment |
| Action | Action type code (e.g., STEP_STARTED, COMMENT_ADDED, INSTANCE_PAUSED) |
| Message | Rich-text HTML content (for comments) or system-generated description |
| IsForceAction | Boolean flag marking force actions for visual distinction |
| Step ID | Optional reference to the step involved |
Viewing Audit History
Section titled “Viewing Audit History”Instance History Tab
Section titled “Instance History Tab”- Navigate to the instance detail page
- Click the History tab
- Browse the chronological list of all changes
- Each entry shows the timestamp, user, action type, and description
- Expand an entry to see the old and new values (JSON diff)
Template History
Section titled “Template History”- Navigate to the template detail page
- Click the History tab
- Browse template-level actions (creation, role changes, deprecation)
- For version-specific actions, select the version from the version dropdown
Step Change History
Section titled “Step Change History”- Open a template version in the editor
- Click the History icon on a step to view its change history
- See all modifications, including content diffs, reordering, and paste operations
- For pasted steps, the source template and version are recorded
Filtering Audit Entries
Section titled “Filtering Audit Entries”Audit views support filtering to help you locate specific entries.
Available Filters
Section titled “Available Filters”| Filter | Description |
|---|---|
| By user | Show only actions performed by a specific user |
| By action type | Filter by action category (e.g., status changes, role changes, comments) |
| By date range | Specify a start and end date to narrow results |
| Force actions only | Show only force action entries (execution log) |
| By step | Show only actions related to a specific step |
Using Filters in the Execution Log
Section titled “Using Filters in the Execution Log”- Open the execution view for an instance
- Navigate to the Execution Log tab in the notes panel
- Click the Filters button to reveal filter options
- Select one or more filter criteria
- The log updates to show only matching entries
- Click Clear Filters to return to the full log
Force Action Audit
Section titled “Force Action Audit”Force actions receive special treatment in the audit trail due to their exceptional nature.
Identification
Section titled “Identification”- Execution log entries for force actions have the
IsForceActionflag set totrue - In the UI, force action entries display with a red background
- The execution log’s “Force Actions Only” filter isolates these entries
Recorded Information
Section titled “Recorded Information”Each force action audit entry includes:
- The specific force action type (Force Complete, Force Skip, Force Abort)
- The mandatory reason provided by the Instance Head or Deputy Head
- The consent acknowledgment
- For cascade operations: which child steps were affected and their previous states
Real-Time Audit Updates
Section titled “Real-Time Audit Updates”Audit entries are created synchronously with the actions they track — there is no delay between an action and its audit record. When viewing audit history in the UI:
- New entries appear in real time via SignalR
- The execution log updates immediately when any user performs an action
- Historical views (History tab) may require a page refresh to show the most recent entries
Data Retention
Section titled “Data Retention”Audit data is stored permanently in the database alongside the entities it tracks. There is no automatic purging of audit entries. This ensures that the complete history of any instance or template is always available for review.
Best Practices
Section titled “Best Practices”Regular Review
Section titled “Regular Review”- Review force actions quarterly or as required by your compliance framework
- Check API audit entries for unauthorized access attempts (403 responses)
- Monitor for unusual patterns (e.g., excessive force actions by a single user)
Using Audit Data for Process Improvement
Section titled “Using Audit Data for Process Improvement”- Identify steps that are frequently force-skipped or force-aborted — these may need template updates
- Analyze step completion times (from audit timestamps) to refine planned durations
- Review step-level comments and notes for recurring issues that could be addressed in the template
Compliance Documentation
Section titled “Compliance Documentation”- Export audit data before archiving instances (see Data Exports)
- Maintain a record of force action reviews and their outcomes
- Document any audit findings and remediation actions taken
Related topics
Section titled “Related topics” Data Exports Export instance data, execution reports, and compliance documentation
Instance Detail View and manage instance configuration, team, variables, and execution