The Basics

What it is

The AuditHistory is a pattern that utilizes the DataTable component to display a chronological record of changes made to a dataset, object, or user action within an application. The AuditHistory pattern can be used as a popover or a standalone table, both of which offer searching, filtering, and pagination capabilities.

Utilizing a specific pattern for record change information is essential for maintaining transparency, accountability, and consistency, especially in applications that require compliance and auditing.

What is a pattern

In general definition, components are the simplest expression of combining colors, shapes, and fonts into an element that has a singular purpose and generally one type of interaction. Whereas a pattern is an assembly of multiple components.

 

However, in Forge we view components and patterns in a slightly more nuanced way to support both developers and designers. We view components as non-separable interface elements that are bound together with code, meaning they have a unique implementation in the Forge developer library to support advanced features or state management. Whereas, we view patterns as an assembly of multiple components that are not rigidly bound by code. Rather, they can be assembled directly by product teams from existing Forge components. For more details on this nuance, refer to the components, patterns, and layouts guidelines page.

 

Both patterns and components are represented in Forge in the 'Components & Patterns' for ease of finding. However, instead of the typical Forge component write-up, patterns are a set of instructions for building a particular solution using other components. The instructions will include which components to include, how they should be laid out, and a live demo of the pattern.

 

To use this pattern as a designer, copy the 'AuditHistory' component from the Forge Figma library and modify the text content as needed.

 

To use this pattern as a developer, view the code in the demos below, copy it, and modify it based on the content specified by your designer.

How it works

At base, all implementations of AuditHistory include information on who made a change, when that change was made, and a description of the change. Additional information can be captured as needed. AuditHistory is available as a popover component triggered by an icon or button or as a standalone DataTable. 

In both styles of the AuditHistory component:

  • Users can view a list of audit entries, each representing a specific action or change.
  • Optional search functionality allows users to quickly find specific entries based on keywords or criteria.
  • Optional record filtering enable users to narrow down the displayed entries by various parameters, such as date range, user, or action type.
  • Users can download the audit history in CSV format for external use or reporting purposes.
  • Pagination can be implemented to manage large datasets, allowing users to navigate through entries easily.

When to use

  • To provide users with a transparent view of changes made within the application
  • To help users track specific actions or changes for compliance and auditing purposes
  • To facilitate troubleshooting by providing a historical context for data changes

When not to use

  • For displaying data that does not require historical tracking
  • In scenarios where a simpler display of information would suffice

What to use instead

List

Use a list if you're trying to display data in a non-interactive, less structured manner.

Accordion

Use an accordion if you have a collection of conceptually related pieces of content that does does not need to be searchable, filterable, or paginated.

How to use

Use AuditHistory to organize record change information in a consistent, parseable format that your users expect.

In areas with limited space, or applications with simple record change information, consider using the popover format of AuditHistory.

In areas with complex record change information or lengthy entity titles, use the standalone variant to provide more visual space for users to interact with data.

Style

Design details

No additional information for this component.

Placement and hierarchy

Demos

In Popover Share

In Popover Basic Share

Audit History Share

Audit History Basic Share

Coding

Developer tips

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Content