Table of Contents

Views and Naming Conventions

LearningBuilder uses naming conventions to differentiate views created from different sources. Please consider the following standards when looking for a data source:

• vALL_CAPS represents a system view. All implementations will have the same system views
• ALL_CAPS represents a view directly from a table.
• vdev_ALL_CAPS represents a custom view created by a developer (please clarify).
• vdiag_ALL_CAPS represents a system view that contains diagnostic information
• vsOBJECT_WORKFLOW represents an Entity View created though the Object editor.

Common Views

Most of the reports used in LearningBuilder can be constructed from built-in views. The following views represent the most common views for daily use:

• vPROFILE
• vPLAN_INSTANCE_QUEUE

vPROFILE view

vProfile is used to report on aspects of a person's Member record. It attempts to extract the most likely information a reporter will want to access about a Member. It includes information directly from the Member record, as well as references to Role and Learning Plan (a.k.a. Application) attributes that are especially important to a Member. To fully understand the sources of the vPROFILE view, a person needs to understand the distinction between a Member, a Role, and an Application (a.k.a., Learning Plan). The vPROFILE view does nothing to explain the source of its information, so it is important to understand the design of the view.

The view draws upon aspects of the system as follows:

• Member record for information directly associated with the Member, such as name, status, primary email address, and communications preferences. This information is stored in a Member table and is not configurable.
• Logical conclusions about how to contact a Member when there may be multiple choices, such as the "Primary Address." This information is stored in a separate table because a person may have multiple addresses. The view accesses only the address marked as "Primary" on the My Account page.
• Logical conclusions about a Member's credentialing cycle, such as Cycle Start and End dates. This information is stored on each Learning Plan, so the view is designed to access only the most recent.

For more detailed information about the vPROFILE view, see the vPROFILE view entry.

vPLAN_INSTANCE_QUEUE view

As the name suggests, this is the view that governs most of the fields available in the Eligibility and Audit queues. The vPLAN_INSTANCE_QUEUE shows information related to a member's applications. The view assembles common information about the Member and the Member's application. There is some overlap between the vPLAN_INSTANCE_QUEUE and the vPROFILE, as they both extract information from the Member, Role, and Learning Plans tables. The primary difference between the vPROFILE and the vPLAN_INSTANCE_QUEUE is that the vPLAN_INSTANCE_QUEUE is intended to support reports that need to understand the distribution of applications in the system, whereas the vPROFILE is more agnostic to application details.

Use the vPLAN-INSTANCE_QUEUE for the following kinds of reports:

• Determine how applications are distributed in the queue with respect to application status, submission dates, etc.
• Generate a mailing list of all applicants in the system

Entity Views

For circumstances in which we need access to the Extrinsic Attributes information contained in an Activity or Activity Instance, we use Entity Views. These views are assembled from the attributes available to each entity. Entity views can contain any Intrinsic or Extrinsic attribute available to the entity type in question. For example:

• Create Activity Workflows → Activity / Activity Instance Attributes
• Member Role - Grant → Role Attributes
• Complete Learning Plan Workflows → Workflow Attributes

Notice that the governing entity is always on the Grant (for Member Role) and Create (for Activities). There are no separate views for Role Edit or Complete Activity Workflows. The concept here is that Role - Edit and Complete Activity workflows are ways to populate an entity, but the entity itself is governed by the creating workflow. For more information on workflows, see:

• Member Role - Grant / Member Role - Edit Workflows
• Create Activity Workflow / Complete Activity Workflow

Activity Entity views are governed by Activity Type, so each Activity Type will have its own Entity View. 

Please see Manage Entity Views for more information how to construct Entity Views for various objects.