Data Integrity Gateway (DIG) power guide

Introduction

Data Integrity Gateway (DIG) is a dynamic tool that helps you increase the accuracy of your organization's data for survey and evaluation automation. With DIG, data clean-up can be distributed to a wide group of users minimizing the burden on any one individual. Typically, users that are already familiar with their organization's data are assigned to review the data.

DIG seamlessly integrates with any information system and allows you to:

• Automate processes - Automate data integrity projects from start-to-finish.
• Maintain integrity - Ensure enrollment data is accurate, up-to-date, and error-free.
• Expand data - Add additional data to expand current data set.
• Enrich analytics - Leverage complete, valid data for new insights.

Why do I need DIG?

Today, more than ever, organizations are faced with complex data issues in their information system (SIS, LMS, HRIS, ERP, CRM, etc.). The sheer volume of information, coupled with 'dirty' data, poses some very costly challenges. Data is often inaccurate, incomplete, or not up-to-date, making it impossible to make informed decisions. Critical information may be missing such as primary subject details, user information, relationship details, and more. The result is a steady decline in data quality and the need for time-consuming cleanup. DIG helps you to ensure the accuracy and completeness of your organization's data, helps you augment your data for better reporting and improves data quality by eliminating manual intervention.

How does DIG work?

DIG supplies your data preparers with a staging environment where they can easily review, correct, or supplement records with certain constraints. Data preparers may mark records as successfully validated and ready to be used in their survey and feedback gathering campaigns.

What can I do with DIG?

• Verify demographic data.
• Modify demographic data (one record at a time or in bulk).
• Add or remove relationships between users (e.g., instructors, students, employees, etc.) and the subject(s) being evaluated (e.g., courses, departments, etc.).
• Combine two or more subjects to be evaluated into one (Merge).
• Create new subjects to be evaluated from an existing subject (Split).
• Mark data as verified (Published).
• Delegate the above privileges to people within your organization (Data preparers).
• Set rules to ensure demographic data is valid.
• Automate reminders to your DIG data preparers to complete their tasks.
• Automate the data flow to your evaluation projects.

Some examples in Higher Education:

• Demographic verification and modification for courses, instructors, students and more
• Splitting: Creating new courses / course sections from existing courses
• Merging: Combining courses (e.g., cross-listed) into a new course
• Modifying student-course enrollments
• Modifying instructor-course relationships
• Modifying instructor’s role per course

Some examples in Enterprise:

• Demographic verification and modification for employees and departments
• Modifying employee-department relationships
• Modifying employee-manager relationships

Who can use DIG?

DIG can be used by various stakeholders within the organization such as:

• Central administration (e.g., HR, IR, IT, etc.)
• Department or cohort representatives
• End users (e.g., instructors, employees, etc.)

Which data types can be treated in DIG? Who can use DIG?

You can treat the following data types:

• Date/time
• String
• Numerical value
• Regular expression (email addresses, phone numbers, postal codes, etc.)
• List

Common terms in DIG

Depending on your region, the terms used in your organization may vary. Common terms that are used in DIG:

Course evaluation - The typical course evaluation refers broadly to the student end of class summative survey in a college/university. Other common terms used for course evaluation include "student evaluation", "learning feedback", "student feedback", "paper evaluation", "module evaluation", and "teaching effectiveness survey".

Course - Course refers to a unit of teaching that typically lasts one academic term. Other terms used for course include “class”, “module”, and “paper”.

Datasource - Also known as a table or “view”, a datasource is a dataset that is applied towards a survey campaign. It can contain the survey respondent information, including students’ or instructors’ names, email addresses and other demographic data that will be useful in the analysis (user datasource). A separate datasource can contain items to be evaluated, such as a list of courses in course/subject evaluations (object datasource).

Demographics - Demographics refer to the characteristics and attributes of individuals, groups or subjects within a datasource. These characteristics often include but are not limited to name, age, location, education, job title, and any other pertinent information that helps define and categorize subjects and users within Blue.

Delegation module - A delegation module is a software component or system feature that allows users to delegate certain tasks, responsibilities, or permissions to other users within a system. In Blue, delegation modules are used to request certain individuals or groups to prepare an aspect of the evaluation process. Examples of delegation modules in Blue are assigned tasks such as DIG, Rater Selection (RS), Question Personalization (QP), and Subject Management (SM).

Blue evaluation project - A Blue evaluation project involves the collection, aggregation, and analysis of feedback data related to student performance, course effectiveness, teaching methodologies, and other relevant metrics. Other terms used for Blue evaluation project include “survey campaign”, “feedback campaign”, and “feedback module”.

DIG project - A DIG project involves the automation and delegation of data preparation tasks to a group of users within an organization.

Data preparer - A person within the organization who is assigned to review, edit, and publish data (DIG task owner).

Transformed data - Data that has been verified and marked as published in the DIG user interface.

Merged course - A merged course refers to a combined entity that integrates course material, student enrollment, and administrative functions of two or more individual courses.

Split course - A split course refers to the division of a single course into multiple distinct sections or components.

Planning

Blue and DIG offer many solutions to prepare you for your survey campaigns. To get you thinking of the best approach, let’s review a series of questions about your organization's needs and what level of delegated control will best serve your requirements to automate the data flow to your evaluation projects.

DIG versus other delegation modules in Blue

Should I use DIG or Rater Selection?

Recommendation: Use the flexibility of DIG to let HR validate certain data known centrally ahead of Rater Selection. Use Rater Selection to allow employees or managers to complete the picture unknown to HR (e.g., who are my peers, clients, etc.) with rules, such as minimums/maximums per group and allow selection only within the employee's office.

Should I use DIG or Question Personalization?

Recommendation: Use the flexibility of DIG to centrally set parameters that can be used to trigger certain questions to be displayed or hidden. Use Question Personalization to make it easy for users to select or add questions to their specific evaluations based on the min/max limits you set.

Should I use DIG or Subject Management?

Recommendation: Use the flexibility of DIG to centrally set parameters that will affect the timing and modality of the evaluation. Use Subject Management to make it easy for users to opt-in or out or to set the evaluation timing within certain constraints.

Conclusion

Consider if you need a combination of delegation tasks. The DIG data preparation phase typically serves as a precursor, facilitating the delegation to big-picture stakeholders with greatest flexibility. It is used to review or edit multiple records at once. Blue's delegation modules (i.e., Rater Selection, Question Personalization, Subject Management) are purpose-built, making it easy for users to make their selections within your specified parameters. Most organizations will consider using both DIG and Blue's delegation modules in sequence to achieve the best results.

Demographic fields

Which fields should I make available to view or edit?

Share fields that are helpful to your data preparers while adhering to the data privacy rules set by your organization. Keep in mind that certain non-editable fields may be useful reference points for data preparers modifying certain fields. While less is usually recommended, data preparers can easily hide fields that they find less useful in the DIG user interface.

What if I only want data preparers to modify some of the data?

DIG supports a hybrid approach to data modification. Certain fields can be automatically synchronized with your datasource without being displayed or affected by any work done in DIG. This is also true of relationships. For instance, you may choose to synchronize course-student enrollment relationships directly with your SIS but allow data preparers to modify only the course-instructor relationships.

Furthermore, you may choose which subset of records to include for review or modification in your DIG project.

Why would I use DIG rather than change data at the source (SIS, HRIS, etc.)?

At times, modifying the source data may not be feasible due to it containing sensitive information beyond what you wish to share with others. Additionally, the data within the data source often serves a very specific purpose that may not align with the objectives of the survey campaign, making it difficult to format evaluations and ensure results are properly analyzed. By using DIG, you can simplify the evaluation process, ensure comprehensive analysis, and enjoy the added benefits it offers.

Why would I use DIG rather than change the data in Blue using Record Management?

Unlike DIG, Record Management is designed for handling individual data changes rather than bulk modifications. Also, changes made in Record Management may be overwritten by subsequent data imports. Manual data management is a key feature of Record Management, and it does not offer functionalities such as setting validation rules available in DIG.

Relationships

Can I modify teaching roles with DIG?

Yes. With DIG, you may display course-instructor relational demographics such as teaching roles per course and contact hours. These demographics can be configured to be editable in the DIG user interface.

Can I add instructors to the evaluation who are outside of the system?

Yes, you may add external instructors to the evaluation process using DIG. This means you can include one-off seminar presenters or guest speakers in your evaluations if you wish to. This can be done by creating a new member within the group for the course.

Dates

Should I set my evaluation dates directly in DIG, program the evaluation timing based on existing dates, or let the users decide?

There are three methods for managing dates in Blue. Depending on your needs, you may choose to use one or a combination of the following three methods: 1) Task Schedules, 2) DIG dates, and 3) Subject Management.

• Method 1 - Task Schedules - Complete automation with the flexibility to define rules for evaluation start and end dates based on various criteria, such as percentage of duration between two dates or fixed and relative dates. However, it's centralized and can only be configured by administrators.
• Method 2 - DIG dates - DIG evaluation start and end dates, providing a centralized approach to managing evaluation timelines within the platform.
• Method 3 - Subject Management - Subject Management, specifically for dates required for Fillout task.

Throughout the evaluation process in Blue, it's common to use all three methods for managing dates. By employing these methods collectively, administrators can efficiently manage evaluation timelines and ensure consistency across all evaluations.

Cross-listed subjects

Institutions often assign multiple course IDs to the same course. For instance, a mathematics course might be identified as BUS345 in the School of Business and as ENG318 in the School of Engineering. Despite the different IDs, these represent identical courses attended by both business and engineering students. Depending on the reporting requirement, data may need to be reported separately for each course listing, or it may be aggregated for the course as a whole. Such courses are commonly referred to as cross-listed courses within institutions.

Assuming I want combined results in reporting, at what point in the evaluation process should I merge courses together?

In Blue, there are three methods for managing cross-listed subjects. Depending on the complexity of your data, you may choose one of the following three methods: 1. merging subjects in reports, 2. merging subjects directly in DIG, 3. leveraging course-student relationship demographics in the datasource.

• Method 1 - Merge subjects in reports - Merging subjects in reports allows for analyzing courses individually or as combined courses. To learn more, see Merge subjects (Cross-listed courses) in reports.
• Method 2 - Merge subjects directly in DIG - Merging subjects directly in the DIG task centralizes the management of DIG task delegation. To learn more, see DIG data preparer task guide.
• Method 3 - Leverage course-student relationship demographics - All courses are already merged, and the distinctive cross-listed IDs are included in the course-student relationship demographics (and displayed to students only when completing their surveys). To learn more, see Leverage relationship demographics (Cross-listed courses).

What if I want to evaluate the same course and instructor multiple times?

You may do this by splitting a course with DIG. Splitting a course allows you to create as many new courses as needed based on the original course, with distinct demographics and enrollment data for each if needed.

Another non-DIG solution is to create separate evaluation projects using the same data and setting different timelines per project.

Final evaluation project configurations

How does my evaluation project know when to consume the DIG data?

Once the DIG task is successfully published, a built-in field called 'Transformed' will go from 'No' to 'Yes'. Apply a Transformed=Yes filter in your evaluation project (Definition > Subject filter) to only accept records that have been successfully published.

DIG project types

The following four DIG project scenarios and settings presented in this section are provided solely as examples. This section will list all the steps to implement DIG into your institution, you have the option to duplicate any of the DIG project scenarios to serve as a template and then customize the settings according to your organization's requirements.

Type 1 – Courses only

If you wish to have a DIG project with only courses as the primary subject, this is what you will need.

Example of DIG project type 1 task:

Type 2 - Courses, instructors & students

If you wish to have a DIG project with courses as the primary subject and instructors as the secondary subject, this is what you will need.

Example of DIG project type 2 task:

Type 3 - Courses, instructors & students (with splits & merges)

Example of DIG project type 3 task:

Type 4 - Employees (360 relationships)

Example of DIG project type 4 task:

Implementing DIG

To set up a DIG project and process in your institution, there are four main stages which, when completed, will automate the process of assigning data preparation tasks to the appropriate users.

The following sections provide step-by-step instructions for setting up DIG. The instructions are broken down into 4 stages which are listed in the table below. The end result of this implementation will enable you to set up and manage a DIG project to validate data before launching a survey campaign for your organization.

For preparation guidelines and concepts, refer back to the Planning section above.

Stage 1 - Create the DIG datasource(s) and definition

1) Creating the DIG datasource(s)

DIG requires special datasources that differ from standard Blue datasources in that two copies of the data are created, an original working copy and a published prepared copy. The original working copy is the focus of a DIG project and controls all of the data that is modified during DIG. The published prepared copy is immediately available for use in Blue projects even before any data has been published via the DIG tasks. After data has been published in a DIG task, automated updates are immediately propagated to the prepared copy used by Blue, based on user defined rules which ensures that the work done during DIG isn't lost once data is imported again.

2) Create the DIG definition

A definition establishes a relationship between subjects in one datasource and users in a different datasource. Filters can be applied to both the subjects and the users to refine the definition.

1. Navigate to Definitions.
2. Select Create Definition.
3. Enter a Definition Title.
4. Add a short Description.
5. Select DIG as the Type.
6. Choose a Subject Source from the available list.
7. Include an easy to recognize name.
8. Select Save to create the definition.

9. Navigate to Definitions - Groups.
10. Select add to create a group.
11. Enter Data Preparers as the Group Name
12. Choose Links to in the Link Type drop-down.
13. Choose the Datasource you previously added that contains user data.
14. Set Reference ID to User ID in the Link Field drop-down. The users datasource chosen in the group will be automatically selected.
15. Keep default values in Member Options (min, max, etc.).
16. Select Create.
17. Select Save at the top right of the page to finalize the creation of the group.

Stage 2 - Configure the DIG project

1) Create a DIG project

1. Navigate to DIG Projects and create a new project.
2. Choose one of the available DIG definitions.
3. Decide if Automatic Update should be enabled for either the subject or any of the existing groups. When enabled, additions and modifications to the subject datasource or group datasource will be included in the project even after the project has been published.
4. Click Create to establish the project and begin adding information.

2) Add basic DIG project information

Before going any further, your DIG project needs a name and some basic information. This information may appear in user tasks and reports, but Project Description, Category, Subcategory and Designer are primarily used within Blue to easily locate the project.

1. Name the project.
2. Provide a brief description of the project.
3. Select a Category and Subcategory as necessary.
4. Create a custom Welcome Message by using HTML markup and field mapping symbols. The welcome message is displayed at the top of the first page of the DIG Task.
5. Save the project before proceeding.

If you have enabled Automatic Update for your subject or groups, then this is a good time to navigate to Info - Options to control member removal in the subject datasource or group datasource.

3) Establish the DIG data structure

The data structure is based on the project definition, but allows the project manager to choose the secondary subjects that are relevant to the primary subject (based on the chosen definition) for this project. Secondary subjects can be anything or anyone that has a direct relationship with the primary subject.

Choose the secondary subjects relevant to this DIG project

1. Navigate to Data - Data Structure for the project.
2. Click Add Secondary Subject.
3. Select one of the available Secondary Subjects.
4. Choose the appropriate Relationship Datasource.
5. Enter a descriptive name for the secondary subject in Display Name. Users assigned a DIG task will see this name, so it should be recognizable to them.
6. Enable Automatic Update to ensure that the unpublished and unverified subjects and secondary subjects in the DIG task are updated when the datasource is synced. Subjects that have already been published will not be updated.
7. Enable Automatic Relationship Sync to provide up-to-date relationship connections between the subjects and secondary subjects. The relationship between subjects and secondary subjects is updated regardless of whether or not they are published. The actual subject and secondary subject are not affected, only their relationship.

8. Save all changes.
   

Example of DIG project type 4 data structure:

4) Select data fields for the DIG end user task

Field Selection allows the project manager to choose which primary subject and secondary subject fields will be seen by users preparing the data, which fields the users will be able to modify, and which fields must contain information before a record can be published. Primary subject fields appear at the top of the page followed by all secondary subjects.

Select data fields that will be displayed, can be edited and/or are required.

1. Navigate to DIG Projects - Data - Field Selection.
2. Select fields for the primary subject that will be shown to the users preparing the data, select fields that can be altered by those users, then select fields that are required before the records can be published.
3. For each of the secondary subjects (established in the Data Structure), select the fields that will be seen by the users preparing the data, select fields that can be modified by users, then select fields that must be completed before the records can be published.
4. Save all changes.

5) Select subjects for the DIG project

Subjects are the people, places, or things that form the focus of the project.

Only the selected subjects will be included in the project. By default, there are no subjects selected. However, if automatic update is enabled when the project is created, then all subjects are included.

Click Select All Subjects to add all available subjects to the project. To add specific subjects, click Select Subjects. The Selection List appears displaying all the available subjects for the definition.

Click Add after selecting the subjects to include in the project. Alternatively, click Add All to include all of the subjects based on the current filter conditions.

6) Assign members to subjects

Group members assigned to a subject will be responsible for updating the data for that subject using the DIG end user task.

Add Members

Members can be added to a subject three different ways:

7) Create DIG data validation rules

Data rules are used to ensure that the users being asked to complete a DIG task are only able to add valid data that conforms to expectations. Rules can apply to either items in a datasource (Datasource), a specific field within a record (Record), or within subgroups of a group (Subgroup).

In the case where rules conflict, the most recently added rule takes precedent.

Datasource rules

There are three conditions that can be used to define datasource rules.

• Split
• Merge
• Add/remove

Record rules

There are five conditions that may apply to record rules.

• Regular expression
• String
• List
• Date
• Numerical value

Subgroup rules

Create subgroups to categorize subject members belonging to the same group.

Example of DIG project type 3 data rules:

8) Manage access to the DIG project

Blue provides multiple levels of security for DIG projects, allowing you to control who has access to a project and what they can do within a project.

Share access with Project Managers

All Blue Administrators have access to any DIG project, but only the selected Blue Project Managers and Blue Project Manager Assistants that have been included in DIG Project - Access are able to view and modify this project.

Adjust the Features Available to the end user working with DIG Tasks

The DIG end user task contains several features that can be enabled or disabled by project administrators. The options found within Data - Options for a DIG project include:

• Allow all users to access Data Import/Export - when enabled, DIG task owners are able to access the Data Import/Export page.
• Only Administrators can publish data - when enabled, only users with an Administrator role in Blue will be able to publish data.
• Allow the task owner to modify their records after publishing - when enabled, users will be able to modify published records in the DIG task.

9) Set up DIG task notifications

Configure the invitation emails and reminder notifications for the DIG task. If any of the email related fields (Sender Name, Sender Email, CC, etc) are left blank, the defaults from System Configuration will be used.

1. Navigate to DIG - Tasks.
2. Enter the required information in the Invitation Email settings.
3. Enter an email address in the BCC field; this should not be an individual’s working email address, but one that is reserved to monitor the messaging process (this step is optional, but strongly recommended).
4. Configure the link text that will be included in the email. This link is highly sensitive to proper syntax. Use $($ at the beginning of the link text and use $)$ at the end of the link text, e.g. $($Complete your data preparation task.\$\)\$
5. Set the start and end dates.
6. Configure the reminder content, dates, and other settings.
7. Save.
   

10) Publish the DIG project

Publishing a project sets in motion a number of events. Tasks will be created for all assigned users. Invitation emails will be sent to each user as their task becomes active. Finally, assigned tasks will begin to show up on the dashboards of users.

1. Navigate to the Publish page for the project.
2. Set a Project Start Date.
3. Set a Project End Date.
4. Send yourself a Test Email and validate that the content is OK and the links are functional. A similar email will be sent to all group members once the project is published.
5. Validate the project and resolve any errors or warnings that are identified.
6. Prepublish the project (an optional step primarily used by project assistants that don't have the ability to publish a project).
7. Publish the project.
8. Save.
9. Export Summary to download a CSV file summarizing when the DIG task for each subject is scheduled to start and when it is scheduled to end.
   

Stage 3 - Manage the DIG project

Once the DIG project has been published, assigned users will perform the DIG task and prepare the survey data by reviewing and validating. Users that have been assigned DIG tasks are able to review, edit, and publish data that has been assigned to them. They will receive email notifications as a reminder to regularly review the data assigned to them. To view instructions on how to navigate the DIG task from the perspective of an end user, see DIG data preparer task guide.

You may choose to manually manage your tasks with features specifically designed for the project manager, focused on managing tasks either individually or in bulk. To view the TASKS page, navigate to your DIG project and select manage DIG project from the header. To learn more about how to manually manage tasks, see Manage tasks.

Stage 4 - Configure the evaluation project

Once the DIG task is successfully published, a built-in field called 'Transformed' will go from 'No' to 'Yes' in the prepared data and the validated data from the DIG project is now ready to be consumed by the evaluation project. Your evaluation project must use the same DIG datasources that were used in your DIG project. To view specific steps on how to create a typical course evaluation project, see Create end-of-term course evaluations.

Before publishing, you must apply a Transformed=Yes filter in your evaluation project to only accept records that have been successfully published from the DIG task.

Once your evaluation project has a Transformed=Yes filter applied to it with other typical settings configured, your survey campaign is now ready to publish with validated data.

Troubleshooting FAQs

Appendix

DIG process & data flow diagram

Datasource stages in DIG process

1. Original data - Source data that has been imported from outside of Blue.
2. Prepared data - Final data that will be used in your Blue evaluation project.
3. Staging data - Data that has been reviewed, modified and validated in the DIG end user task.

Explanation of DIG process & data flow diagram