This article provides some recommended practices when designing Appian Records. For other topics related to Appian records, see:
To walk through an example of creating your first record, see the record tutorials on the Tutorials page.
As a designer, the first thing you should ask yourself is, "Am I taking advantage of the full potential of Appian Records?"
Unlike traditional records, or the records in your database, Appian Records are a new type of record that allow you to see your business information from a number of different perspectives. Appian Records allow you to bring all of your data together in the form of configurable record lists and record views and allow users to take action in the context of that information. This includes both integrated business data, such as customer information or payroll information, and process data, like support tickets created through an record action.
See Using the Records Tab to see examples of how others implement Appian Records and find your own inspiration.
Records don't need to be defined entirely in the record type; keeping definitions in external objects can improve maintainability.
Appian recommends saving any expressions created for a record type as a rule for version control and testing purposes. This also allows you to re-use the rules for a different record type.
rp! domains are not available from within the rules management interface. This means that if you try to test a rule that references
rf!, the rule will not evaluate. It is better to pass all of the record data into the rule as inputs.
For instance, a rule for a Summary View should look like the following, where the
getMyView rule defines one rule input each for the
getMyView(rf!customerName, rf!industry, rf!contactInfo)
Record types are referenced using the
recordType! domain and
<record name>, as shown below.
recordType! domain to reference the record type for use in functions, such as
urlforrecord(). See Appian Functions for more information on functions that reference a record type.
Records are one of the most important pillars of your applications. As a result, they are often one of the most complex objects to design and optimize performance for.
Attributes that affect record list performance:
Attributes that affect record view performance:
You can visualize the performance breakdown of your record type UIs by navigating to the Performance page while configuring your record type.
The record list view is an equally important part of record design, as it's how users find the information they're looking for; a well-designed record list view can increase the value of your records.
Appian will automatically optimize the image for display on web and mobile clients that support a variety of screen resolutions and pixel densities. Manually reducing the source document size may result in certain users seeing low-quality icons with improper layout.
When selecting the document source for the records images, make sure it results in images that help users identify each record easily. For example, using a company's logo as the image for each record in a Companies record type helps the user find a company by glancing at the record list view. Using the same generic icon for all listed companies would not. Similarly, you should not use a user object for the record list view image unless that record represents the person or is very strongly tied to that person.
If the data source for your records has existing rows that are flagged as deleted (such as rows of the data store entity or processes of the process model), consider creating a default filter to hide them from the record list view.
Up to 100 records display in a list view. If the number of records for a record type exceeds 100, create simple alphabetical user filters so that each option displays up to 100 records. If using the grid-style list, users will be able to page to see more data.
When users visit the Records tab, they'll be primarily focused on finding a particular record and viewing specific information that pertains to it. Follow the best practices below to ensure users can easily scan through your records.
To create visually-balanced record views, it is recommended to use the same layout (one-column or two-column) for all sections. Two-column layouts provide greater density for short text values, smaller charts, and grids. One-column layouts provide additional space to show longer paragraphs of text, as well as charts and grids that contain more data points. A one-column layout is recommended for grids that include more than 5 columns and/or lengthy text content. Charts that show more than 7 data points are generally best-shown in one-column layouts.
When including multiple sections on a record view, make sure that the height of content in each column of two-column sections is similar in order to minimize white space.
When mixing different layouts on the same record view, it is preferable to place a one-column section above a two-column section; this reduces the likelihood of a shorter column creating empty space above the start of the next section. An example of an effective mixed-layout record view is a grid in a one-column section above a two-column section containing a variety of brief text and number data values.
Use concise labels to describe record view fields. Most of the space within the record view should be used to show data values; avoid having verbose labels distract from content. If detailed description of a value is needed for proper comprehension, provide instruction text instead of a lengthy label.
Group related fields into sections described by concise labels. This will help users quickly scan record views to find relevant information and also reduces the need for redundant text in field labels.
The following suggestions apply only to the record list view.
Adding repetitive prefixes, such as categories, to record titles only adds noise to the record title and doesn't help users locate the specific record they're looking for.
Long record titles, especially those wrapping onto multiple lines for mobile applications, make it harder for users to quickly browse through the titles.
If record titles are defined by complex expressions that evaluate differently for one user over another or include metadata (such as a priority level or task count), it makes it difficult for users to discuss or search for the same record without confusion over the title. Specific functions to avoid include
Long, paragraph-style, descriptions reduce the number of records that are visible on the screen at the same time. They are also harder to read when quickly scanning down the record list than either a shorter sentence-style description or a series of label/value pairs separated by line breaks.
The timestamp for records on a record list view is optional. Since the timestamp is not labeled, one should only be shown if users are likely to understand its meaning without further explanation. For example, when an event represented by the record occurred. If there is a requirement to show timestamps which require explanation, include them on the record views where they can be shown with explicit labels.
Using the Records Tab: Provides instructions on how to use Records as a user.
Create a Record Type: Provides instructions on how to create a record type for your application.
Record Types: Provides you detailed design information.
Records Tutorial: Walks you through an example of creating your first record.
Interface Tutorial: Walks you through an example of creating your first interface, which is the basis of a record view.
Interface Components: Lists the supported interface components and the data structure required for adding them to a record view.
On This Page