Activity Definitions

An Activity Definition (often referred to as just an "Activity") represents something that a user needs to do as part of a Learning Plan. Activities are created when an administrative user (either an admin or a Provider member) completes a Create Activity workflow in the Provider area of LearningBuilder.

There are two main examples of Activities:

1. Generic data entry task - Activities can be used to represent a generic data entry task on a Learning Plan. In this approach, the Activity itself does not contain any specific "context"; it represents a generic thing, and the end user provides all of the context when they add the Activity to a Learning Plan and complete its Complete Activity workflow. These Activities are often created by site or client administrators.
   
   
2. A specific "thing" the user can add to their Learning Plan - Activities can also be used to represent specific things, such as a specific continuing education course. In this approach, adding the Activity to a Learning Plan represents that the user has taken that specific course or attended that specific school. Thus, some of the "context" is baked directly into the Activity itself. The end user may still provide some additional context, however, such as the date they took the course or the dates they attended the school. These Activities are often created by 3rd party Providers.

Activities are not directly added to Learning Plans - see "Activity Instances", below.

Activity Types

Since the process of defining different types of Activities may be different, LearningBuilder supports multiple different Activity Types. Each type is configured with two different Workflow definitions:

• The Create Activity workflow defines the process through which a new Activity of this type is created.
  • When the Activity represents a generic data entry task the creation workflow is often very simple, collecting only a few fields (like Title)
  • When the Activity represents a specific thing, such as a specific continuing education course, the creation workflow is more elaborate and will collect additional information. In the case of 3rd party Activity Providers, the creation workflow will likely include a Payment step as well.
    
    
• The Complete Activity workflow defines the process through which a new Activity Instance of this type is created. This is what controls the workflow that an end user sees when they add the Activity to their Learning Plan.

Multiple Activity Types can share the same workflow definitions.

Activity Instances

Activity Instances are the primary way that a Practitioner enters data on a Learning Plan Instance. They establish a link between a specific Activity and a specific Learning Plan Instance and then allow that link to be personalized with additional data.

For example, consider an application that requires the user to enter information about their Work History. It would work like so:

1. Practitioner is viewing their Learning Plan and clicks the "Add Activity" button in the "Work History" Task Group
2. A list of Activities in the "Work History" Activity Type is displayed. For instance, there may be two entries:
   1. Pre-graduate Work History
   2. Post-graduate Work History
3. Practitioner selects the "Post-graduate Work History" Activity.
4. System creates a new Activity Instance that joins the "Post-graduate Work History" Activity to the Practitioner and then launches its Complete Activity workflow.
5. Practitioner fills out the workflow, entering information such as their employer name and employment dates. This data is stored on the Activity Instance.

The Complete Activity workflow grants read-only access to the Activity's data attributes and write access to the Activity Instance data attributes.

Definitions vs. Instances

Common Examples

Examples of common Activities include:

Work History section of an initial Application

The application to become credentialed often requires that the applicant document their work history. This is often achieved by creating a single Activity Definition that represents a generic job position and then requiring the applicant to fill in the details (such as employer name, hours worked, etc).

This is implemented by:

• Creating a single Activity called "Generic Work History"
• Creating a Learning Plan Task Group that requires the user to enter at least one Generic Work History activity
• Capturing the specifics of the job position (employer, etc) as attributes of the Activity Instance

In this scenario, the Activity is created by a Member of the licensing board itself (or a Heuristics analyst).

Education section of an initial Application

Just like Work History, but the applicant enters information such as University, Degree Type, etc. There is a single Activity representing a generic degree, and the applicant fills in the details (university name, GPA, etc) on their Activity Instance.

Continuing education courses for a re-certification Learning Plan

Once a Practitioner obtains a license, they usually need to maintain the license by participating in ongoing continuing education. Often, they do this by taking courses from one or more "approved Providers". This is achieved by creating multiple Activities, each one representing a specific approved Course. The licensee then adds the relevant Activities to their Learning Plan to represent the courses they completed.

This is implemented by:

• Creating multiple Activities, each one representing a specific course
• Clicking the "Add Course" button on a Learning Plan displays a list of courses (Activity Definitions) that the user can pick from
• Practitioner enters the date they took the course as part of their Activity Instance data, but all of the other details (the course name, the number of CE units its worth, etc) come from the Activity Definition

NOTE: compare and contrast this approach, where the Activity fully defines the Course and the Practitioner simply enters the date they took it, against the above examples where the Activity is totally generic and the Practitioner provides ALL of the context. 

In this scenario, the Activity is created by a Member with the Provider role.

Exam results

An Activity Instance is, at its core, just a data collection device that can be attached to a Learning Plan. When an application includes an exam, we often model it as an Activity Instance.

This is implemented by:

• Creating a single Activity that represents the exam details
• Creating a Learning Plan Task Group that can hold that type of Activity
• Using a Workflow Behavior to send the "authorization to test" to the exam provider at the appropriate part of the Complete Activity workflow
• When the exam is completed, the exam provider makes an API call back to LearningBuilder to update the Activity Instance with the exam results

Related articles

• Page:
  Manage rules governing Activity Instance duplication (LearningBuilder Documentation)

  • activity
  • activity_multiple_instances
• Page:
  API/ActivityInstance/GetOrCreate (LearningBuilder Documentation)

  • api-get-or-create-activityinstance
  • api
  • activity
• Page:
  Task Group Activity Search (LearningBuilder Documentation)

  • activity
  • task-group-activity-search
• Page:
  Activities (LearningBuilder Documentation)

  • activity
• Page:
  Training - Activity Basics - Add a Task Group that accepts a 3rd party Activity (NEEDS REVIEW) (LearningBuilder Documentation)

  • activity
  • activity-instance
  • training