Tempo reports are a way of pulling in data from tasks, records, relational databases, and other third-party data sources and displaying it on a single SAIL in Tempo for end users to view. Through the use of rules, SAIL components and expressions, Tempo reports enable designers to quickly define what data to display and how to display it in a usable and concise way on both web and mobile clients.
The sections below detail design information for Tempo reports, such as what to expect in terms of report security, the options available when configuring a Tempo report, and how to manage them after their creation.
To walk through an example of creating your first Tempo report, see also: Grid Tutorial
Where do Tempo reports display?
Tempo reports display in the Work Platform interface. By default, they display on the Reports tab. If configured as a task report, they display on the Tasks tab.
How do Tempo reports differ from process reports?
Tempo reports can easily be modified through their expression, be viewed on mobile devices and the broad set of web browsers supported by Tempo, and report on data from tasks, records, and relational databases. process reports can only be viewed from the Portal and can only report on data from process models, processes, and tasks.
What happens to my process reports?
These continue to work as before in the legacy Portal interface as part of Appian. As you migrate your application to Tempo, you can design Tempo reports for each process report, including Task Reports, and access these from the Tempo interface.
Can I Import/Export Tempo reports?
Yes, Tempo reports are like other Appian objects in that their definitions can be deployed between development and production systems using application containers.
Do I have to use Tempo reports when I upgrade?
No, you can update to the latest version of Appian without any required re-work. You can begin using Tempo reports when you choose.
Can I have multiple components on a Tempo report?
Yes, the report's expression displays arrays of components in a single-column layout, or you can display arrays within specific layout components, such as DashboardLayout, to display more than just a single chart or grid.
A Tempo report is an Appian object that displays charts and grids based on an expression. It holds the basic properties of the report (such as name and description), the expression that determines what SAIL components display, and the role map that determines its security.
Tempo reports can display data queried from tasks, records, and relational databases.
You can display the data through any of the SAIL components, including chart components and basic field components.
See also: SAIL Components
Task reports are a subset of Tempo reports. They are accessible from the Tasks tab alongside the system's existing task views. You can configure any Tempo report to be a task report while creating the Tempo report object, but Appian recommends only configuring those reports that display a grid with process task links.
Security for Tempo reports can be defined at two levels. Access to the data displayed, and access to the report in Tempo.
Data security is based on the security of the underlying data source. The expression runs under the context of the user viewing the report. Users must have at least viewer rights to the data to view it on the report, but Tempo report security alone will not stop them from viewing the data in other areas of the system.
For example, not giving a user viewer rights to a Tempo report prevents the user from seeing it on the Reports tab in Tempo, but the data might still be visible in a process report or process dashboard. On the other hand, if a user has viewer rights to a Tempo report, but they do not have access to the data used in a component on the report, the user will see the report in the list, but the report may fail to render or just the component with the restricted data will fail to render. Again, this depends on the expression and the source security.
Each Tempo report has a rolemap specifying its viewers, auditors, editors, and administrators. When creating the Tempo report, only one group can be added to each role. Users must also have at least viewer rights to the different pieces of data to view it on the report.
The rights for each role include the following:
|Actions / Roles||Administrator||Editor||Auditor||Viewer|
|View in Tempo||Yes||Yes||Yes||Yes|
|View the Tempo report configuration||Yes||Yes||Yes||No|
|Delete the Tempo report||Yes||No||No||No|
To access the Tempo report object’s definition and rolemap, users must also be in the designer role.
See also: Designer Role
Tempo reports can be created by any user in the designer role.
Creating a report involves the following:
See the following SAIL Recipes for examples of creating charts using
Name: The name of the Tempo report. Only accepts a Text value. For example, Yearly Earnings, Tickets by Status, or Tickets by Priority.
Description (Optional): The description of the Tempo report to be displayed in the Reports list view. Only accepts a Text value. For example, Summary of Yearly Earnings Broken Down by Quarter, Number of Tickets Broken Down by Status, or Number of Tickets Broken Down by Priority.
Save as Task Report (Optional): Enables the Tempo report as a task report.
Interface: Interface that calls the interface you created.
The system automatically generates a URL stub when you save the Tempo report object. For example, "lstM7Q".
Once the Tempo report is created, the report is available for all users with at least viewing rights. The URL stub created for the report can be shared between users but will only work for those that can already view the report.
The following basic properties of a Tempo report can be edited:
To edit these basic properties, complete the following:
You can also edit the interfaces associated with the Interface value or add and remove users or groups from the report’s security groups.
To change whether or not a Tempo report is a task report, you must create a new report.
Only the latest version of the Tempo report is saved in the system.
Any changes you make to the rules created as part of the SAIL Dashboard, however, are saved as a new version just as any other rule.
See also: Editing Interfaces
Deleting a Tempo report removes the object from the system. It will no longer appear in Tempo.
Save Report Configuration Expressions as Interfaces
Appian recommends saving any expressions created for a report as an interface for version control and testing purposes.
This also allows you to easily copy parts or all of the interface to create similar reports for different data.
Keep Report Names Simple and Concise
Each Tempo report’s name should be easy for users to scan through.
Limit the Number of Series Values and Categories
The number of series values for a chart component affects performance. The fewer values that need to be evaluated, the better the performance.
Limit the Number of Chart SAIL Components on the UI
Each SAIL component added to a Tempo report also impacts the report’s performance. This especially applies to chart and grid components. The more complex each component, the higher the strain on performance. Keep this in mind when adding more than one complex component to your report.
Limit Queries to External Databases
Store external data or the result of expressions that do heavy data manipulations in local variables defined using load() to avoid re-executing them upon every reevaluation. Use local variables to avoid redundant queries when configuring one or more components that use the same data.
Review and Adjust the Chart
As discussed, many factors affect the size, layout, and performance of a chart. Be sure to review the chart as it displays in Tempo and apply the best practices above to tweak the end result. Modifying your rule for the SAIL Dashboard in one browser while viewing the Tempo report in another is a great way to see the impact of your changes easily.
Keep Report Names Concise and Descriptive
Users should easily be able to understand the purpose and content of each Tempo report from its name. Since reports are sorted alphabetically, related reports should use names that start with the same text (such as the name of the record type being reported on) so they are grouped together on the report list, e.g. “Customers by Industry” and “Customers by Region”.
Use Appropriate Column Layouts for Report Content
Two-column layouts provide greater density for smaller charts and grids, allowing users to see more data without scrolling and facilitating side-by-side comparisons. One-column layouts provide additional space to show 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.
To create visually-balanced reports, it is recommended to use the same layout (one-column or two-column) for all report sections. When mixing different layouts within a report, make sure that the height of content in each column of two-column sections is similar in order to minimize white space. For the same reason, 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 report is a grid in a one-column section above a two-column section containing a variety of smaller charts.
Keep Chart Labels Short
Long label text may reduce the amount of space available for the plot area of charts. When there is limited room to show chart labels, some text may overlap and certain labels may be hidden to preserve space.
Minimize the Number of Chart Series and Categories
Design charts with as few dimensions and data points as needed to optimize display. Simpler charts are easier to comprehend and also load more quickly.
Line charts or column charts with a large number of data points will require users to scroll horizontally to view all the data.
Pie charts with a large number of slices, particularly if some of the slices are very thin (values with small magnitude compared to the overall data represented), may display with some data labels not visible. If this cannot be avoided, enable tooltips so users can see data values by hovering over pie slices.
Limit the Number of Grid Columns and Keep Text Short
Grids with a large number of columns, long column header labels, and/or long text data values will require users to scroll horizontally to view all columns. Use a one-column layout to allow more grid columns to be seen without scrolling. Consider reformatting or abbreviating label and data values to reduce their character length.
Accessible Reports Must Provide a Plain-Text Representation of Data
While charts are an effective medium for visually presenting data, they are primarily intended for consumption by sighted users. To make the same data available to non-sighted users who interact with Appian through a screen reader, provide a grid view of report content. See this recipe for an example.