Dynamic Role Access (DRA) power guide

Introduction

Dynamic Role Access (DRA) is a tool that helps you manage report access for academic leaders, such as deans and department chairs. You can easily assign or change access rights for these users based on their roles and responsibilities. Instead of manually updating each report, DRA can automatically synchronize with your institution's organizational hierarchy to grant access. This saves time and effort, and ensures that academic leaders can access the reports they need.

Is DRA right for your institution?

If you answer yes to the following questions then Dynamic Role Access may be right for your institution.

• Are reports shared with academic leaders?
• Is access to a report determined by leadership roles (e.g.: dean, associate dean, department chair, etc.)?
• Is your institution's organizational structure based on a hierarchical tree model?
• Is access to reports updated throughout the year?
• Do academic leaders need access to historical reports?

What is involved in setting up DRA?

To set up DRA for a project, there are three main stages (see diagram below) which, when completed, will automate the process of rerouting reports to new or different individuals who have been assigned to existing roles in the organizational hierarchy.

How long does it take to set up DRA?

The time required for each project may vary, but usually it ranges from 1 to 3 hours. This includes the initial planning and the activation of your organizational groups in the reports. After the setup is done, you can easily change one dean for another in a matter of minutes—or, even better, it can be done automatically once you synchronize your organizational structure. For older reports, you may need some extra time to fix any data that does not match your current organizational structure.

The following planning sections describe the components of DRA and provide various scenarios to consider or adapt to your institution’s roles, hierarchy and relationships.

Planning

Organizational Roles

Which organizational roles will you choose to set up DRA for your institution?

An organizational role is a specific function that an individual performs at an institution or organization. The roles you will need to set up DRA will vary depending on who will access which reports.

Consider the following scenario:

1. Deans need to access School / Faculty level reports.
2. Associate Deans need the same access as their Deans to access School / Faculty level reports.
3. Deans and Department Chairs need access to Department level reports (Department is one level below School / Faculty in this example), but Associate Deans must not be granted access to Department level reports.
4. Deans, Associate Deans and Department Chairs also need access to individual instructor reports.

Can you use less roles vs. more roles?

In the example above, Deans and Associate Deans share the exact same access rights for School / Faculty reports as well as individual instructor level reports in requirements #1, #2, and #4. You could combine the ‘Deans and Associate Deans’ roles into one single role simplifying your setup and enabling you to have less roles to manage, however requirement #3, indicating that Associate Deans do not have access to Departmental reports, requires you to maintain a separate role for Associate Deans. In this example, using less roles would prevent you from having the granular needed for these roles.

Should you add instructors as an organizational role for report access?

No. Giving instructors an organizational role for report access is unnecessary and not recommended. Most instructors only need to see their own individual reports.

Are any of your instructors also academic leaders who need to have access to organizational level reports?

These instructors / academic leaders usually have complementary roles based on your organizational structure. For example, a department head who is also an instructor will have access to their own personal instructor reports in addition to reports for other instructors under their purview. As a department head, this user’s access to reports is managed through the organizational hierarchy structure in DRA (see hierarchies below) and can change as the user moves from one role to another, whereas the instructor report access is static and does not change automatically if they are no longer have that role.

Hierarchies

Is your organization’s hierarchy complex? How much of it should you bring into Blue?

To explain what hierarchy means, we can use a tree as an example. A tree has branches that divide into smaller branches, and each branch represents a different node or unit in your organization and how they connect to each other. For example, we could create a departmental hierarchy used for Course evaluations:

A University (level 1) would be at the top, followed by a School of Arts and Science (level 2), which has a Department of Anthropology (level 3), and a Sub Department (level 4) that offers a Genetic Anthropology program, which teaches the DNA 101 course (base level). This hierarchy has 4 levels plus the base Courses level. Courses are not included in the hierarchy setup but linked to organizational units in a later step.

To add your hierarchy to Blue, create a hierarchy data file such as the table below containing the 4 levels and the data required for this hierarchy.

Your naming conventions can be different from the example shown above, such as the following common hierarchy:

• Level 1 - University
• Level 2 - Faculties
• Level 3 - Schools
• Level 4 - Modules

What if you have two different (parallel) hierarchies that aren’t fundamentally related to each other?

Your institution may have sets of organizational units that belong to distinct hierarchies. A common example is a Campus Hierarchy that doesn’t quite fit inside of the Departmental Hierarchy. One campus may contain courses from several departments, and these same departments may have courses taught at different campuses. Trying to fit campuses into departments or departments into campuses could prove problematic. In this case, we recommend that you consider two separate hierarchies that work in parallel, both belonging to the same root: Level 1 - University.

How does the hierarchy get linked to your course data?

Your courses data file will be referenced to the organizational unit IDs for each course. These references are represented by fields (columns) in your courses table, one for each level of the organization. For example, if you have a 3-level hierarchy, you will need at least two fields (the top level is implied, so it is not required) that contain the level-2(School ID) and level-3 IDs (Department ID) for each course.

Example of course data showing two reference fields containing organizational units

Relationships

How will you link people to the hierarchy?

The next step involves assigning people to their respective organizational units. There are three elements to consider:

• who they are (UserID),
• what organizational unit (OrgUnitID) they are tied to
• what organizational role (OrgRoleID) they play in relation to the unit.

To illustrate this concept, we have added the people who require access to reports with their corresponding roles in each level of this hierarchy.

To add these relationships to Blue, create a Relationship data file, such as the one below:

Can the same person play multiple roles?

Yes. For example, Amy K Choy (Leadership ID: akchoy) could be a Department Chair in one department and an Assistant Department Chair in another. This would be represented by two different records, both of them containing the LeadershipID Akchoy.

What if your academic leaders need access to instructor reports?

Throughout this document, we have described a hierarchy with courses at the base level, meaning that courses belong to a school, department, module, etc. You can also create a hierarchy with instructors at the base level, meaning that instructors are linked to a school, department, sub department, etc. The core elements are the same: Your instructor data will need references (columns) that identify the organizational units they belong to.

If your academic leaders need access to instructor reports, it may be useful to map one hierarchy to courses and another to the instructors. For example, you could have a hierarchy based on departments for courses and a hierarchy based on the academic affairs institutional office roles for instructors. This way, you can make sure that relevant academic leaders can access the reports for the courses they oversee, and those who manage instructors can access instructor reports. DRA is designed to support both cases, and they can work in parallel.

All the notes in this document can apply equally to a course or an instructor-based hierarchy. You will be able to specify in your projects whether to map your hierarchy to the course or the instructor.

Implementing DRA

The following sections provide step-by-step instructions for setting up DRA. The instructions are broken down into 3 stages which are listed in the table below. The end result of this implementation will enable you to connect the desired organizational groups for each parent report with a simple toggle.

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

Stage 1 - Set up organizational roles, hierarchies, and relationship datasource

Set up organizational roles

Navigate to System Administration - Organization - Roles where you can add, remove and edit organizational roles. Create as many organizational roles as required, but remember the Organizational Role ID must be unique.

Set up a hierarchy template

A hierarchy template is a prerequisite to configuring the hierarchy datasource.

1. Navigate to Organization - Hierarchy Templates
2. Click Add to create a Hierarchy Template
3. In the side panel, enter the name of the hierarchy (e.g., “Departmental Hierarchy”)
4. Add the number of levels you will need and provide a name for each level.
5. Click Save to complete.

Hierarchy datasource

A hierarchy datasource must contain only three fields, the organizational unit ID, the organizational unit, and the parent ID.

Set up a hierarchy datasource

1. Navigate to ADMIN - DATASOURCES
2. Click Add Datasource
3. Provide a name (required) and description (optional)
4. Select Hierarchy from the Type drop-down menu
5. Select the Hierarchy Template you will be using.

6. Click Create to add a hierarchy datasource.
7. Configure the data blocks** in DATASOURCE - DATA.
8. In DATASOURCE - IMPORT/EXPORT, specify the Organizational Unit ID the Organizational Unit (the caption), and the Parent ID. These are required fields for the hierarchy datasource. If there are other fields present in the file, they will be ignored.
9. Finalize the import.

10. Set a schedule as needed in Datasource - Import/Export - Schedule.
11. Rename hierarchy levels in Datasource - Display Settings.

Setup a relationship datasource

1. Navigate to Datasources
2. Click Add Datasource
3. Provide a Name (required) and Description (optional)
4. Select Relationship from the Type drop-downmenu
   
5. Click Create to add the relationship datasource.
6. Configure the data blocks in Data.
7. In Import / Export, specify in the Datasources section which hierarchy datasource to use as the Source and which users datasource to use as the Target:

8. In Import / Export, specify in the System Fields section which is the organizational unit ID in the hierarchy datasource (Source ID); specify which is the User ID in the users datasource (Target ID) and which is the role column in the users datasource (Organizational Role ID). Finalize the import.
9. Set a schedule as needed in Import / Export - Schedule.
10. In Display Settings, you may rename the levels of the hierarchy if needed.

Stage 2 - Set up organizational links and create organizational groups

Set up organizational links

This section enables you to apply your hierarchy and organizational relationships to your project based on your responses to the following questions:

1. What columns in your project data represent the different levels of your hierarchy?
2. What groups should you create based on the organizational roles you defined?

Once the project is configured, your reports will be ready to leverage the new organizational groups you have created, and these will update automatically based on changes you make to the relationship datasource.

In Organizational Links, you will map the data of your project with the levels of your hierarchy. This allows your projects to fully integrate with the hierarchy and relationships datasources you created.

1. Go to: Projects > Select Project (Edit mode) > Definitions > Organizational Links
2. Click Set Organizational Link to add a new link and enter a name for this link (e.g., ‘Linking subjects to my departmental hierarchy’, or ‘Linking subjects to my campuses hierarchy’).
3. Select the datasource that contains the hierarchy datasource you would like to map to the project’s data.
4. Select whether to map the hierarchy to the primary subjects (e.g., courses) or secondary subjects (e.g., instructors).
5. Select the hierarchy-to-leadership relationship datasource to apply to this project.
6. You are now able to map the columns in your project’s data with each level of the hierarchy. All but the root level must be mapped.

7. Once the tasks above are completed, you may Verify Mapping. Verification helps you identify any issues between your hierarchy and relationships and the data in your project. This can help you troubleshoot issues with certain users who are not receiving access to their expected reports. Keep in mind that the mapping will only look at current and active (non-deleted) data within your project and not data that may be added at a later time, which is likely to occur if your project is live.
8. Click Add Organizational Link to add your link to the project. You may repeat these steps for additional organizational links for this project.
9. Save your project to apply the changes.

Create organizational groups

Create the groups that will be used in your reports. Create groups that are one-to-one with the roles you created (Deans group = Deans role only), or you may combine several roles together (College Level group = both Deans Associate Deans roles).

1. Go to Project - Definitions - Group.
2. Click Add Group.
3. Enter a Group Name that will be easy to distinguish in reports.
4. Select whether the group will be linked to the primary (courses) or secondary (teachers) subjects.
5. Select the Organization Link Type. This link type is only available if you have an Organizational Link (created in the previous section) based on the primary or secondary subjects you chose to link this group to.
6. Under Organization, select the Organizational Link you set up in the previous section.
7. Select at which level of your organization you would like this group to be linked.
8. Select which Organizational Roles should apply to this group.
9. Select the Report Viewing Privilege. If this option is not selected, the members of this group will not be given report access.
10. Save your project to apply the changes.

Repeat these steps for each group you wish to connect to your project’s reports.

Stage 3 - Connect groups to reports and filter report viewers

Connect organizational groups to reports

Now that your organizational groups have been created, they will be available to activate (“connect”) in a special section of your report called Dynamic Viewers. Here you will see a listing of all the organizational groups you have configured for the project associated with this report. Connecting these groups to the report ensures that your reports assign the respective academic leaders to their reports. It also updates their access nightly with changes you may make to your organizational structure (i.e., by modifying either the hierarchy or hierarchy-to-leadership relationship datasource).

1. Navigate to Reports.
2. Edit a report.
3. Navigate to Viewers - Dynamic viewers.
4. Toggle on the organizational groups you want this report to connect to (e.g., select only Dept Chairs for departmental reports).
5. Check the Receive notification emails option for this Dynamic Group so that all users will receive an email when a report is ready for review.
6. Click Get Latest to see a preview of which child reports your dynamic report viewers are associated with. In case the same report viewer appears multiple times, you will also see their Organizational Role and the Group they belong to. You may also filter the list based on the viewer’s name, role or report title.
7. Click Save Report to apply these connections.
   • If your report is not yet published, the dynamic viewers will not have access to their dynamic reports until the report has been published.
   • If your report is already published and active (not expired), the dynamic viewers will have immediate access to their respective reports the moment you save the report.
     

Update your users nightly synchronization (2:00 AM ET):

Ensure your report is published and not expired. There are no other settings needed for the automatic update of Dynamic Viewers.Dynamic

Filtering report viewer groups

In projects RV groups have a behavior that is different from all other types of groups. Users who are part of RV groups will be pulled in from the data sources instead of the project snapshot. It is important to note that filtering in the project will not affect the demographics of report viewers.

When to deactivate email notifications for certain Report Viewer groups

If a large number of reports become available for certain Report Viewer groups, consider not activating the Receive notification emails to prevent overloading their email inboxes. Instead, send them a manual email through Blue as needed or encourage them to regularly visit the Blue Home page to check for reports.

To send a manual email to a Report Viewer group:

1. Go to Reports > Select report (Manage mode) > Report Management
2. Select Report Viewer from the View filter dropdown list
3. Select the dynamic group you wish to email from the Group filter dropdown list. This will filter the list to only the viewers you are interested in emailing. Note: You may also select Static Viewers separately as needed.
4. Click the Email button to compose and send the email.

Making modifications

The following sections provide information on managing changes to your DRA solution:

Special cases

Not all configurations are the same, and not everyone has the same starting point. Here we will examine some special cases.