Data containers render records and related data for display in Workflows. Data containers can incorporate data, documents, or a combination for a given object type.

What is a data container?

Data containers dynamically display field data, like data collected on a Slate Hosted Application, or by a form submission.

Using Configurable Joins, the contents of a data container can reach beyond those of the specific application page or form in question.

A data container can be configured to include any data from a record, including data collected in custom widgets. They can likewise exclude any data points not appropriate for review. The data can be ordered, formatted, and filtered as needed to optimize your review process.

Building a data container

✔️ Prerequisite Skills:

Workflow Tabs

To build a data container:

1. Select Database from the main navigation.

2. Under Reader and Decisions, select Workflows.

3. Select an existing workflow from the list, or click New Workflow to create a new one.

4. Select the Reader Tabs tab.

   

5. Click the Edit Materials icon on a Material-type tab.

6. Select or drag data container from the palette at right. The New Data Container popup appears.

   

Next, we'll decide what type of container object we want to create.

Choosing the container's object type

Building a data container is similar to building a query. In a query, the query base determines what each row will represent. Likewise, a data container's container object determines what each page will represent.

Consider the experience you would want when reviewing an application. The example we'll take here is the presentation of school information on the application:

Example A: One school per page

Should each school on the applicant's record be displayed on its own page, with accompanying transcripts and a high level of detail for each institution? Selecting an object type of School results in a new page for each school associated with the workflow object's record.

Example B: One page, multiple schools

Or would a condensed all-school resume make more sense, displaying a list of schools along some other data points? Matching the object type with the base of the Workflow (in this case, Applications) and making joins to each school condenses the data from multiple schools onto one page.

Data containers can accommodate either approach, with ample opportunities for customization. Select an object type that fits your process, then click Continue. The remainder of this article will work from the School object type.

Determining the container's properties

Container properties display the overall conditions for viewing the data container. They include:

• Status: Active or Inactive.

• Tab: Confirm or Choose a Reader Tab in which the Data Container should display. The Data Container can be moved in its entirety from one Reader Tab to another within this workflow, including filters.

• Stream Type: Same as the container's selected object type.

• Template: Choose a Template. Auto-PDF option is the default, meaning that the font and conventions will mimic those in Auto-PDFs throughout Slate without pulling in any branding. Institutional template files will display here in the reader to incorporate chosen branding into the data container.

• Memo: Include a Memo if needed. This will only display within the Workflow editor and is a tool to include notes on the Data Container. If two Data Containers have the same title, this can also serve to distinguish between them.

• Filters: Include filters as needed. Filters selected here are scoped to the current Workflow and do not correspond to the stream or object type of the data container: they determine for which records the Data Container will display.

When you've finished configuring the Properties tab, select the Page Builder tab.

Determining the container's contents

The Page Builder tab determines which data display on the data container, in what order, and in what format. Add exports from the Base/Stream type you selected (in this example, School), or join to additional data to determine which exports should appear.

Configure the following settings in the Page Builder tab:

Page title

Enter a Page Title. This will display at the top of the data container within the workflow.

✨ Tip

Create a dynamic page title by prefacing the name of the first export with "Section: " The name of that export replaces the page title field. This also works with concatenated subquery exports, as with this example (School Name, School CEEB If Exists).

Data container with static title (pulled in from Page Title field).

Data container with dynamic title (pulled in from first export).

Exports

This is the heart of the data Container, where the content is selected, labeled, and formatted.

Sections & headers

In addition to creating dynamic page titles when used on the first export in the list, prepending "Section: " to subsequent exports or literals creates a page break.

Add a header row by prepending "Header: " to the title of any export. Unless their title includes "Section: ", literals are automatically formatted as headers.

Literals

Literal exports organize the flow of information in the data container by surrounding direct exports and by formatting concatenated information in subquery exports.

A concatenated subquery export can also account for address formatting. Using literals within subquery exports lets you incorporate spaces, parentheses, line breaks, and punctuation, displaying applicant data in an intuitive and reviewer-friendly way.

Subquery exports

Within subquery exports, literal values still appear even if data do not exist. Use nested subquery filters to prevent stray literals from showing up in your data containers.

In the example opposite, the subquery export Institution consists of the nested direct export School Name and the nested subquery export School CEEB if exists. The latter export includes literals for parentheses.

If CEEB was instead a direct export, and we brought the parentheses up to that same level, they would appear around an empty space for schools for which a CEEB does not exist. Placing those literals in the subquery export prevents this type of formatting error from happening.

Data containers grow or shrink based on the data provided

When joining to multiple related records from the base of Person or Application, you'll find that not all students have a value for all chosen exports. For example, while you might want the potential to display up to five schools, most students will have only one or two.

Data containers account for this: rather than displaying empty lines where schools don't exist, direct and subquery exports in a data container won't display without a value (unless you specifically configure a null value).  Additionally, literal exports (including headers) won't appear without values present before and after.

Filters

Add filters if needed to limit what results will be returned as pages. In a data container of object type School, filters could be used to exclude all schools of a level of study not relevant to the workflow.

Sorts

Add sorts if needed to determine page order. Pages within a given type of stream will automatically display in the order Rank – Ascending.

🔔 Important!

If you are joining to multiple objects from the stream type Application in subquery exports, be sure to use consistent sorts across each export. This ensures exports are appropriately grouped and correspond with the desired display order. Direct sorts apply only to the Stream Type.

Adding documents

If the object type you've selected for your data container is associated with a Material scope, a third tab appears: Documents. In this example, the data container's object type is School, so the documents available in the Material Type list are school-scoped.

Documents selected here are dependent on the filters and sorts from the Page Builder tab for this object type. This determines the order that the Schools and associated transcripts display overall within the Workflow, and the circumstances under which a School should display at all.

To add documents to a data container:

1. From the Material Type list, select a material that corresponds to the chosen container object. Only materials in the relevant scope appear.

2. Enter a Limit # if needed to determine how many materials of each type should appear.

3. Apply a Sort to the selected documents if needed. Sorts applied in the Page Builder tab will order the objects overall, including their related documents; the sort applied in the Documents tab works within the materials of the selected object type, and does not impact the order in which objects display in the data container. For example, if a school associated with a person record has multiple school-scoped transcript materials, but only the most recent is necessary, entering a limit # of "1" and selecting the sort Descending (Recently Updated First) ensures each object in the data container displays a maximum of one transcript of that material type.

4. Click Add Document to include multiple materials.

Data containers can be used to display and filter materials, even without any accompanying exports configured in the Page Builder tab. For example, in a reader tab in which all official transcripts should be displayed in a certain order without any accompanying Auto PDFs, a data container will allow for more precise filters and sorts than a typical material reader stream. Data containers may replace the material reader stream altogether and allow for the materials themselves to be complexly filtered.