Entities and Entity Views
- Seth Petry-Johnson
- Steve Ross
Entity Views allow administrators to control which data fields are displayed in various parts of LearningBuilder.
This is a complex topic but is central to LearningBuilder’s configurable nature.
Overview
LearningBuilder is very flexible and can collect a wide variety of data for a wide variety of things. Entity Views allow an administrator to control which of those fields are displayed when each type of thing is viewed in different parts of the site.
For instance the information that a Practitioner sees when looking at their own Application might be different than what a Reviewer sees when looking at that same Application within a review queue.
Examples of screens managed by Entity Views are:
The “Role Details” panel on the My Account page
The “Role Details” and “Activity Detail” panels on the Learning Plan Overview
The public Member Details page used by the Credential Lookup / Provider Directory feature
Entities, Entity Types, and Attributes
There is a one-to-one relationship between a Workflow and an Entity. You can access the Entity details from the Admin → Workflows → Edit Workflow page:
Each Entity has an Entity Type that correlates with the Workflow Type:
Workflow Type | Entity Type |
|---|---|
Create Activity |
|
Complete Activity |
|
Complete Learning Plan |
|
Member Role - Grant |
|
Member Role - Edit |
|
Configure Learning Plan |
|
Configure Tenant |
|
Create Offering |
|
Attributes are defined for an Entity Type, not an Entity
When you create a new Attribute on the Admin → Workflows → Edit Workflow screen, the Attribute is defined for the Entity Type, not for the Entity.
Thus, if you create an Attribute for one Complete Activity Workflow, you can also add that same Attribute to any other Complete Activity Workflows as well.
This makes it possible for different Workflows of the same type (e.g. two different Application submission Workflows) to operate on the same set of Attribute data.
View Types and Areas
There are 7 different Entity View Types, documented below, each used by a different feature within LearningBuilder.
Those features can appear in the different Areas of LearningBuilder, and an administrator can choose a distinct set of fields for each Area + View Type combination. This provides maximum flexibility by allowing each feature to behave differently based on where in the site it is being used.
Not every View Type is used within each Area. See below for a matrix of supported options.
Entity View Types
Type | Notes |
|---|---|
Summary | The summary and detail views expose a small list of key data fields and a more comprehensive list of fields, respectively. The Learning Plan Overview Popup and Workflow Overview Popup features allow users to choose which level of detail they want to see. By default, users see the Detail View. They then can change to the Summary view. |
Detail | |
Export | The Audit Queue and Eligibility Queue pages allow users to export data about certification applications. The “Export” Entity View controls the fields that are contained in the export file. This allows the file to contain a more comprehensive list of fields than would easily fit on the screen. |
Report | Controls the data fields that are exposed to the Reporting Engine for a given entity. |
Entity List Attribute | This is an advanced use case that requires extra configuration. The Entity List Attribute is an advanced configuration feature that allows one Workflow to summarize information from other Workflows. This Entity View specifies which fields of each summarized Workflow are included in the list. |
Activity Container List | This is an advanced use case that requires extra configuration. The Activity Container Attribute is an advanced configuration feature that allows for Workflow data to be “nested”. This Entity View specifies which fields of the contained Activities are displayed in the list. |
Attribute Renderer | This is an advanced use case that requires extra configuration. This entity view is used by the https://heuristicsolutions.atlassian.net/wiki/spaces/DOCS/pages/1281589809 API to determine which Attributes are available to be rendered. |
Supported Combinations
Entity Type | Area | View Type(s) | Notes |
|---|---|---|---|
|
| Summary, Detail |
|
|
| Summary, Detail, Report |
|
|
| Summary, Detail | Used when an |
|
|
| Used by Learning Plan Overview Popup on the Eligibility Queue |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configuring an Entity View
See the subsection below for “best practices”
To configure an Entity View, go to Admin → Workflows and locate a Workflow related to the Entity you care about.
For example, to modify the fields that show up in the “Roles” panel of the My Account page, locate the Grant Role Workflow for the Role you want to modify, and then click the “edit” icon.
On the Edit Workflow page, click the “Show Details” link in the page header, and then click on the “View Entity Details” link.
On the Entity Details page, you will see a list of all Entity Views that have been configured. There will always be at least one entry in this table for “Default”.
Any feature that requests an Entity View that is not configured for the target Area will use the Default view.
Clicking “Add View” will display a list of all View Type + Area combinations. Pick the one you wish to configure, and then click the “+” icon to add the fields you wish to display for this view.
Newly added Entity Views are disabled by default. Click the “No” link in the Enabled column to turn it on. When a view is disabled, the Areas and Types it is set up for will use the default view until it is enabled.
After enabling the Entity View, the selected fields should begin appearing in the relevant feature and in the specified Area of LearningBuilder.
Preventing Duplicate Activities in a Learning Plan Task Group
Entities for an Activity Instance have an extra setting that can be used to prevent the same Activity from being added more than once to a single Task Group.
For more information see Manage rules governing Activity Instance duplication | At the Entity level
Configuration Best Practices
Best Practice: It is recommended that the Default view have only those attributes that should be visible to everyone. This is important since new views do not take effect until they are configured and enabled and this will ensure no data that needs to be protected is exposed.
Additional views would be created to expose additional fields in other areas using the copy feature, as needed.
Best Practice: The default view should never have any View Types selected. That view applies to all View Types not defined in another view. Many times, no extra views are needed.
Best Practice: The default view should never be used as the Admin - Reporting view type. Instead, a separate view should be created solely for reporting with the name “Report”. This ensures what you want to include in a report does not also dictate what you see on the screen.
Additionally, the Admin – Report view does not need to be Enabled. It works all the time once a view exists with that type Designated.
Note: For clients using the enhanced reporting engine, this Admin – Report view type is not needed.