This page describes how you can configure record events to capture event data, then use that data to monitor and improve your business processes.
Your enterprise is built on key business processes. Whether it's logging support cases, completing orders, or managing employees, keeping track of who does what and when can help you better understand your business and improve how it operates.
Record events allow you to seamlessly track what happens in your applications and when, with minimal configuration on your part.
Once you start tracking event data, you can use that data to:
You can provide application users with a timeline of events so they can monitor and respond to those events.
For example, in a Financial Onboarding app, an account manager could see at-a-glance the latest activities that took place on a client's request for a new account, so they can decide if they need to follow up on an internal review step that's taking longer than expected.
When capturing data for an activity log, you can track any type of events, including ad hoc events.
As you collect event data, you can display a history of events in your record views, interfaces, and reports using the event history list component. This component is automatically added to any generated Summary view so users can quickly see a history of events related to their records.
You can display your event history as a timeline or as a list to show a snapshot of your business operations. Use the component to display a history of events for all records, or only display the events for a specific record.
You can allow team members to have discussions and ask questions directly in the context of their records.
For example, in a Financial Onboarding app, you can enable collaboration on the Account record type that tracks account changes during the account management process. Then, an onboarding specialist can use the event history list component to ask a manager a question about the customer's documents. The manager receives an email notification about the question, then uses the component to start a threaded conversation about the account.
When you enable collaboration, you can capture top-level comments as ad hoc events and store threaded conversations as additional metadata in a separate record type.
You can analyze the larger behavior of a business process, so your organization can identify opportunities to improve that process.
For example, in the same Financial Onboarding app, the information you gather about activities taking place during the account evaluation could be used to determine how long on average the full evaluation takes or how long a particular sequence of activities in an evaluation takes. With this information, your organization can begin to identify trouble spots in the process itself. Even better, you can investigate your event data using Process HQ to find new ways to optimize your business processes.
When capturing data to improve a business process, you should track events specific to your process. Typically, this means excluding ad hoc events.
When you've collected event data, you can use it to optimize your business processes with Process HQ. Since your event data is stored in your record types, it's easy to capture and prepare the data for process insights.
Before you configure record events, you'll want to make a few decisions about what events to track and when. This section provides guidelines to help you with those decisions.
While you can configure record events on any synced record type, we recommend that you only configure it on record types that represent your major business concepts or processes. You should not configure record events on record types that contain lookup data.
For example, in a Financial Onboarding app, you may have the following record types:
Depending on how you want to use your event data, you could configure record events on the Account record type to track changes that occur in the account management process.
You could also configure record events on the Customer and Employee record types to create an activity log of customer changes (like new zip codes or a change in licensing status) or employee changes (like promotions or departure dates).
It's unlikely that you would need to configure record events on the Region record type, however, since this record type stores lookup data that is unlikely to change.
The types of events (or event types) you track should be meaningful and comprehensive to ensure you get a complete picture of your business operations.
To get the most out of record events, you should track events that represent the main steps in your business process. Ideally, each of those events occurs only once, and the events should occur in a specific order. These events can then be displayed in an activity log or used to improve your business process in process insights.
Let's look at an example of event types for a Financial Onboarding app. In this app, you would want to track when a customer applies for an account and each action your employees take to evaluate that account before creating it. To do so, you would configure the following event types:
These event types represent all possible activities that could occur in this process. A process improvement analysis can focus on times when events are skipped, occur more than once, or occur in an unexpected order. Tracking only these events will give you optimal data for analysis.
Event types should focus solely on the activity that occurs during the event. Avoid using the event type to capture dynamic details about the event. Instead, capture those details in additional fields on the event history record type.
For example, instead of creating an event type called "Financial Review Completed by Angela Lewis," create an event type called "Completed Financial Review". Then, at the time of the event, write the employee who completed the review to the user field of the event history record type. This way, you can still capture details about a particular activity, and your event types will be consistent and easy to understand.
Tip: Since each event represents a completed activity, Appian recommends naming your event types in the past tense.
When you're choosing events to track, avoid tracking case or ticket statuses like "Pending," "In Progress," or "In Review." While the status of the case is important, it doesn’t reflect the actions being done to move the case through the business process. Instead, focus your event types on the specific user or automated actions that cause the status to change.
For example, let’s say you have a record type that stores data about Financial Onboarding cases. While a case moves through the onboarding process, the status updates to reflect its current onboarding phase.
Instead of creating event types like "Pending" or "In Progress," choose event types like "Created Case," "Verified Documents," and "Assigned Onboarding Manager."
Auditing changes in field values can be a valuable monitoring tool, but these audits aren’t well suited for record events. Changed field values can clutter an activity log, and since they don’t necessarily represent steps in a business process, they won’t be helpful for analyzing processes for potential improvements.
Avoid using record events to recreate field-level audits, and instead focus on the user actions and automated actions that occur during a business process.
If you're using event data in an activity log, you may also decide to track events that are expected to occur more than once and at any time during the process. We call these ad hoc events.
For example, in a Financial Onboarding app, an employee might update the customer's contact information at any time (Updated), or a reviewer might add a comment on the account with a question that needs to be answered (Commented). These kinds of events are useful in the context of an activity log, but they're not very useful when analyzing how the evaluation process itself is doing. If you're tracking events to improve your processes, you'll want exclude ad hoc events like comments from process analysis.
When tracking events for any purpose, you should always capture a timestamp when an action completes. For example, in a Financial Onboarding app, you would capture the timestamp when financial document verification is done, with an event type of "Completed Financial Document Verification".
To support process analysis, you can also capture a timestamp at the start of the event, so you can calculate a waiting time between activities.
For example, in the Financial Onboarding app, you can capture a timestamp at the start and end of financial document verification. To follow this approach:
start).start field when the event starts and the default timestamp field when the event ends.Then, to determine the activity duration, you can calculate the time between the start timestamp (start) and the end timestamp (timestamp) of the event. Or to determine the waiting time between activities, you can calculate the time between the end timestamp of one event and the start timestamp of the next event. For example, between timestamp for Financial Document Verification and start for Financial Review.
Record events can be used to track which user or automation takes action on your records, so you can measure how automated a given process is. Use the standard automation types when configuring how your process model writes events, and configure the event history list component to display either the username or automation type for each event.
Once you've reviewed the guidelines above, you can start configuring record events.
Record Events
