User Management is a centralized interface accessible from the Admin Console from which administrators add new users. Admins can configure their site's user groups, the members of these groups, and the permissions associated with these groups. Permissions are used within the software to assign and restrict access to specific actions, features, and data.
This article discusses the following topics related to User Management:
- Access and Permissions
- Key Terms
- Restriction and Visibility Options
- Users Overview
- Groups Overview
- Shared Filters
- Shared Email Templates
- Frequently Asked Questions
Access and Permissions
To access User Management, navigate to the Admin Console > Settings > User Management.
Important Note: In all Terra Dotta products, the system will automatically redirect you to the User Management interface if you navigate to Staff > Staff Permissions in the classic administrative menu.
To view the User Management option in the Admin Console's Settings card and in the left Navigation Menu, the admin must have the following permission:
- Staff Permissions (View)
To make changes to existing groups and users, the admin must have the following permission:
- Staff Permissions (Edit)
To create new users, the admin must have the following permission:
- Staff Permissions (Add)
Key Terms
- Integrated User: This type of user's data is sent to your Terra Dotta site from your institution's student information system (SIS) and human resources (HR) data source. An integrated user will have a UUUID username that serves as the key to authentication and information services, and this user must authenticate (i.e. sign into your site) through the institution’s Secure Campus Login (SCL).
- Non-Integrated User: This type of user's data is not in your institution's SIS/HR file and must be manually entered by the user or an administrator. A non-integrated user will use an email address for their username and will log into your Terra Dotta site with login credentials that have been provided to them.
- Internal User: Someone affiliated with your institution.
- External User: Someone not affiliated with your institution.
- SCL & SIS/HR Integrations: Terra Dotta integrates with outside authentication and information services so that users of those external systems can log into their Terra Dotta site with their pre-existing credentials and have their relevant data imported into the site’s database. These integrations are Secure Campus Login and Student Information System/Human Resources. If a Terra Dotta site has been integrated with the institution’s SCL-SIS/HR services, then the site will have “integrated” users. There is a flag for all users in Terra Dotta to indicate if they are integrated or not.
Restriction and Visibility Options
Restriction and visibility options can be assigned to a group or to an individual user as a way to limit access to applications and data within those applications.
A restriction is an option that can be assigned to a group as a way to limit which applications the group's users can access. This means that a restriction impacts the applications that a user is able to see. If a program and applicant parameter are assigned as a restriction for a group, then users in that group will have access to applications for the selected program. They will also have access to applications where applicants have the selected applicant parameter value.
The following restriction options can be assigned for a group:
- Access to All Applications: Use this option when no restrictions need to be assigned. This means that the group's users will be able to view all applications.
- Access to Assigned Applications: This option should only be used in conjunction with the Application Created Trigger. It will only give group users access to their assigned applications based on the use of the related "Assign Application" action in the Application Created Trigger. If an application has been assigned to a user with the use of this trigger, then they will have access to the application. We look forward to more updates to the Application Created Trigger and application assignment process to further enhance this option. Failure to assign this restriction option correctly will result in users being unable to access applications.
-
Access to a Subset of Applications: Use this option when you wish to restrict a group's access to applications that are for specific programs or for applicants with a specific applicant parameter value.
- Programs: A user group with a program restriction means that users will only be able to view applications for the selected programs. For example, if "Study in Brazil" is selected as a restricted program, then group users will only be able to view applications for the "Study in Brazil" program. It is possible to select a program group or multiple programs at once when making your configurations.
- Applicant Parameters: A user group with an applicant parameter restriction will only be able to access applications where the applicant profile contains the selected value. A "Not In" operator can be used when you want to restrict users to see only those applications where the application value of X is not true.
Important Note: When multiple restrictions are used, they are additive, which means the more you add, the greater the scope of access.
In the image below, a program and applicant parameter restriction have both been applied to a group. With these assigned restrictions, this means that the following is true:
- Group users will see all applications for the "Global Summer Program: France" program.
- Group users will see all applications for those applicants whose "Department" applicant parameter value is not Biology or Chemistry.
This also means that if a user is in a group that has group-level restrictions assigned, then these restrictions will continue to be true for the user as long as they remain a member of that group. Group-level restrictions cannot be modified at the user level. See question #16 in the Frequently Asked Questions section of this article for more details.
Visibility is an option that can be assigned to a group as a way to limit what data a group's users can view within an application. This means that a visibility option functions in the same way as a Data Access Object (DAO) in the classic permissions system as it impacts what a group's users can see in applications.
The following visibility options can be assigned for a group:
- Access to All: Use this option when no visibility options need to be assigned. This means that the group's users will be able to view all data within an application.
-
Access to a Subset: Use this option when you wish to limit what a group can view within applications.
- Questionnaires: A group with a questionnaire assigned as a visibility option means that the users in this group will only be able to see this specific questionnaire within an application.
- Applicant Parameters: A group with an applicant parameter assigned as a visibility option means that the users in this group will only be able to see this specific applicant parameter within an application.
In the image below, a visibility option for a questionnaire and an applicant parameter have both been applied to a group. With these assigned visibility options, this means that the following is true:
- Group users will only see the "General Information" questionnaire within applications.
- Group users will only see the "Advisor" applicant parameter within applications.
Users Overview
The "Users" section of the User Management interface gives admins the ability to create a site user, invite one or more users to a permission group, and manage permissions at the user level.
The "Users" interface is organized as follows:
User Search Tools
- Search for Users: Keyword search field.
- Filters: Choose to search by username, email, first name, or last name.
- Show Staff Members Only Toggle: When enabled, only a list of users who have been assigned at least one permission is displayed. When disabled, all site users are listed. If you search for someone and they do not appear in this listing, then they likely do not yet have a user ID in the site. If a user has been invited and is pending registration, then they will not appear in this listing until after they've completed their registration.
- Pagination: Adjust the number of items listed per page.
Columns
- Username
- First Name
- Last Name
- Actions: Edit or delete user.
Important Note: The "delete" user action does not permanently remove the user from the system. Instead, the action modifies the username and email address so they are appended with *removed and filtered from the search results.
Invite Users
- Use this option to add multiple users to one or more groups and notify them of the update. Existing users are notified that they've been added to one or more groups. New site users are prompted to complete their registration and create a password.
- See the "Inviting Users" section of this article for full details.
Create Users
- Use this option to create and add a single user to one or more groups.
Pending Users
- If you've used the "Invite Users" feature to invite users who need to complete their registration, then the "Pending Users" section will allow you to view any pending invitations, their registration link status, and take such actions as resending or deleting invitations as needed.
Editing a User
To modify an existing user, click on the edit pencil for the respective user in the "Actions" column. This action will route you to an edit page with the user's full information:
Edit User
In this section, the information of a user can be modified. After making your changes, click "Save".
Groups
In addition to the options for editing the user's information, a "Groups" section appears from which you can manage the groups to which the user belongs.
To add the user to a group, select the group from the drop-down menu and click on the "+" icon. The group will drop to the table, and the change will be automatically saved.
To remove the user from a group, click on the "Remove Group" icon. This change will be automatically saved.
Show Advanced Settings
To manage individual permissions for the user, click on the "Show Advanced Settings" link. This action will expand an "Access and Permissions" section where permissions, restrictions, and visibility options can be managed on the user level.
Offices are encouraged to manage permissions at the group level.
Important Note: When the user has a restriction assigned at the user level, an alert icon will appear next to the "Show Advanced Settings" link:
If a user has group-level restrictions, then these can be viewed from the user level but not modified. For example, the user below has a group-level program restriction for the "Global Summer Program: France" program. When the admin views the user's individual permissions from the "Users" section, it is not possible to remove this program because it is a restriction assigned to a group to which the user belongs.
The programs in Japan and Cameroon were added as restrictions at the user level, and this is why the admin has the option to remove them at the user level.
Creating a User
To create a user to add to one or more groups, navigate to the "Users" tab and click on the "+" icon.
This action will open a page from which you will be able to populate information about the user, manage the groups to which they belong, and modify any user-level permissions as needed.
Inviting Users
Regardless of whether a user is integrated or not, the Invite Users option allows an admin to generate a list of users to add to one or more groups at once. Invitees are notified, and those users who are not already registered in the system will be invited to complete that process and generate a password.
To get started, navigate to the "Users" tab and click on the "Invite User" button at the bottom of the page.
This action will prompt the Invite Users wizard to open.
Follow these steps:
1. User Group(s)
Select one or more groups to which you will add your users. A minimum of one group must be selected.
2. Email Addresses
Enter an email address for each user that you wish to invite to the group(s) selected in step one. Each email address must be comma-separated with no spaces between.
After entering all desired email addresses, click "Validate". This action will prompt a table to display with information about each user in columns as follows:
- Type: Non-Integrated or Integrated
- Email:
- Username
- First Name
- Last Name
- Actions: If a user was selected and you no longer want to include them in the invite process, use the delete option to remove them from your invitation.
Non-integrated users are those whose information is not in the SIS/HR file sent from the institution. These users will use an email address for their username and log into the Terra Dotta site with credentials provided to them. For the invite process, an admin would only enter an email address for a non-integrated user. The first and last names will be entered during the registration process by the user directly.
An integrated user has information being sent from the institution's SIS/HR file, and they must authenticate through the institution's Secure Campus Login (SCL). An integrated user will have a UUUID username needed for authentication. Their information will be fully populated in the validation table as follows:
4. Invite Users
When you've confirmed that your desired user group(s) and users have been selected, then you must click on the "Invite Users" button in step four to complete the invitation process.
This action will prompt an automated email to be sent to all invited users which uses the email template located under Process > Notifications > User Invitation. The default message in the template can be modified.
Important Note:
- All users will receive the same email message with one exception:
- If the invitation is sent to a user who already exists in the Terra Dotta site, then they will see a link that directs them to the site's login page.
- If the invitation is sent to a user who does not already exist in the Terra Dotta site, then the will see a link that directs them to a user registration page.
5. User Registration (For those invited users who have not yet been created in your Terra Dotta site)
An invited user who has not yet been added as a user in the Terra Dotta site will click on the appended login link in their invitation email. This will route them to a user registration page from which they will be prompted to enter the following information:
- First Name
- Last Name
- Mobile Phone (optional)
- Password
- Confirmation of Password
After all required information has been entered, the "Create My Account" button will become accessible. The user will click on this button and be routed to a confirmation page. The text on this page, which cannot be modified, will contain:
- A confirmation of the user's username.
- A reminder that they will need to user their username and password to log into the site.
- A link from which they can access the site.
Groups Overview
The "Groups" section of the User Management interface gives admins the ability to create a permission group and manage any restrictions to that group along with members of that permission group. Think of each user group as a unique cohort to which a specific set of permissions have been assigned.
Important Note: Only select special characters are supported in group names. The use of an ampersand is not supported. If a user group previously used an ampersand in its group name, then the group name will need to be modified so that this character is removed in order to proceed with changes to the group, such as those changes to the group's users.
The "Groups" interface is organized as follows:
Group Search Tools
- Search by Group Name: Keyword search field.
-
Filters
- System Group
- Custom Group
- Show All
- Pagination: Adjust the number of items listed per page.
Columns
- Group Name
- Actions: Edit and delete
Create Group
- Use this option to add a group.
System Groups
System Groups are permissions groups that have been pre-made by the software and carry a label to differentiate them from custom permission groups that an admin might create independently. System Groups cannot be deleted, nor can their label be modified.
The system groups of Application Managers, Program Managers, System Administrators, and Website Managers are unique in that they are hard-coded and automatically updated by the software. This means that they each respectively contain all permissions needed for a staff member in a role as an application manager, a program administrator, a system administrator, or a website administrator, and these permissions cannot be modified by an admin. A key benefit of using these system groups is that they are automatically updated by the system when new, relevant permissions are added to the software. For example, if a new feature is added that pertains to managing programs, then the Program Managers system group will automatically be assigned that permission so that admins in this system group can access and use the new feature upon its deployment to production sites.
The system groups of Recommenders, and Reviewers act in a slightly different manner in that these system groups are not automatically updated by the system when new, relevant permissions are added to the software. Because these system groups have been migrated from classic, they may be tied to functionality on your site, as offices have used these classic permission groups differently to support their needs.
The system groups consist of the following:
-
Application Managers
- Members of this user group have permissions assigned for Analytics, Applicant Admin, and Profile Admin.
-
Program Managers
- Members of this user group have all Program Admin permissions assigned.
-
Recommenders
- Members of this user group have no assigned permissions.
-
Reviewers
- This system group is the same as the classic Reviewers permission group. If anyone is in this group and you want to transition to using the current Reviewers Management functionality, then you can create a new, custom Reviewers group by copying the users from this classic group to the new one. Your custom Reviewers group should not need any permissions assigned because permissions for reviewers are based on Reviewer Roles in Reviewers Management.
-
System Administrators
- Members of this user group are often considered power users in the system because they work in the software regularly and are proficient in its use.
- This user groups has permissions assigned for Analytics, Applicant Admin, Course Approvals, Department Management, Maintenance, Process Admin, Profile Admin, Program Admin, Staff Admin, System Settings, and Website Admin.
-
Website Managers
- Members of this group have select permissions from System Settings (Image Library and account information) and all Website Admin permissions.
Custom Groups
A custom group is one which an office has created on their own, and it does not automatically receive any new permissions added to the system. With a custom group, you can edit the permissions assigned and even delete the group.
Important Note: The Facilitators groups is the one custom group which cannot be deleted. Because offices have traditionally used the Facilitators group in unique ways, this custom group may be tied to various functionality on your site. For this reason, an office may choose to leave the assigned permissions for their Facilitators group as is while also using the System Administrators group going forward.
Editing a Group
You can modify a group by clicking on the edit pencil in the "Actions" column for the respective group. This routes you to an interface with four tabs:
- Permissions
- Restrictions
- Visibility
- Users
Permissions
Under the Permissions tab, you can view the assigned permissions for a group.
- A system group's permissions will display in a list format and cannot be edited.
- A custom group's assigned permissions can be modified by adding or removing the desired permissions.
If a site is using multiple products, such as Study Abroad and AlertTraveler, then the option to filter by a specific product line is available.
Restrictions
A restriction is an option that can be assigned to a group as a way to limit which applications the group's users can access. This means that a restriction impacts the applications that a user is able to see. If a program or applicant parameter is assigned as a restriction for a group, then users in that group will only have access to applications for the selected programs and applications where applicants have the selected applicant parameter value.
For full details, see the "Restrictions and Visibility Options" section of this article.
Visibility
Visibility is an option that can be assigned to a group as a way to limit what data a group's users can view within an application. This means that a visibility option functions in the same way as a Data Access Object (DAO) in the classic permissions system as it impacts what a group's users can see in applications.
For full details, see the "Restrictions and Visibility Options" section of this article.
Creating a Group
A new group can be created manually or by copying the permissions and users from an existing group. To get started, click the "+" icon.
This navigates you to a page from which you can get started creating a group with these steps:
1. Enter a name for your user group.
2. Select the option which corresponds with how you wish to set up your new group.
- Set Up Manually: Select the specific permissions for your group. Set any desired restrictions and/or visibility options. Add users one by one to the group.
- Copy Settings from Another Group: Save time and select a group from which your new group will receive its assigned permissions, restrictions, and visibility options. It is also possible to copy users from an existing group to your new group.
3. Click "Create" when ready to create your group.
Shared Filters
Admins with the permission Staff admin > Staff Permissions (edit) will see the Shared Filters tab within User Management page. This tab displays all filters in the account that have been shared:
From this listing, the administrator can open the shared filter for review in a new tab. They can also un-share the filter with a user or group. This can be used in cases where an administrator has shared lots of filters with other administrators/groups and later is no longer an active administrator on the site. This utility helps remove outdated shared filters that are no longer relevant to the admins they were shared with.
Shared Email Templates
The Shared Email Templates tab in User Management allows administrators to see all shared custom email templates on their site:
From here, administrators can see the following:
Email Template Name: The name given to the template by its creator.
Owner: The name of the admin who created the template.
Description: The description of the template added by its creator.
Shared to: The user group(s) the template has been shared with.
Only the template creator can share their template. However, admins with the permissions needed to access User Management can unshare templates when the template creator is no longer active on the site. To unshare a template, click the Unshare icon with the Actions column:
Frequently Asked Questions
1. What is the difference between the custom Facilitators group and the System Administrators group?
The System Administrators group will be updated automatically by the system to contain any new permissions assigned to that group. For offices who used the Facilitators group, you may choose to leave users in that group - and also add them to the System Administrators group. You may also choose to move everyone who was in the Facilitators group completely out of that group and into the System Administrators group.
Terra Dotta's in-app messages will appear to members of both the Facilitators and System Administrators groups going forward.
2. Are users always notified when they are added to a group?
No, they are not.
In the following scenarios, existing users are not notified when they are added to a group:
- Groups > Edit Group > Users > Add User to Group.
- Groups > Create Group > Search for Existing Users.
- Users > Edit User > Select Group to Add.
In the following scenarios, users are always notified:
- If you use the "Invite User" feature, which adds both existing and new users to a group, then the Invite User email notification will always be sent.
- If you use the "Create User" option, then the User Created email notification will always be sent.
3. If a user is a member of multiple groups, one which might have more restrictive permissions than the other group, then how will this be managed in the site?
Everything is additive in User Management. Therefore, it is not possible to restrict a user to a subset of programs in one user group and then not honor that restriction elsewhere.
4. Have data access objects (DAOs) been replaced in User Management?
The ability to restrict access to specific applications and data within those applications still functions as it did previously in the classic staff permissions system. In User Management, the use of a restriction option is the same as restricting application access to those of a specific program, program group, or applicant parameter value. The use of a visibility option is the same as restricting access to data objects, or information within an application based on the assigned questionnaires and applicant parameters.
5. Is there a limit to the number of users who can be invited at once using the "Invite User" feature?
The limit is based on the character limit of 500 for the email addresses in step two of the invite process.
6. When users are invited as part of the Invite User process, how long does the registration link last before it expires?
The link will expire after 24 hours. An admin can navigate to the "Pending Invitations" section of the "Users" tab and resend an invitation if the link has expired before the user has been able to take action.
7. What does the restriction setting of "Access to Assigned Applications" mean? Is this for use with my reviewer groups?
This setting relates to having an application assigned to users in a group based on the use of the Application Created Trigger. It does not mean to only give reviewers access to their assigned applications to review or to only give users access to the programs to which they've been restricted. Unless your office is using the Application Created Trigger, the "Access to Assigned Applications" option should not be used.
8. Is it possible to make a certain group not be considered as staff, specifically "Recommenders"?
Not at this time. The Recommenders user group exists to ensure that the uses are properly routed to the correct landing page when they log in.
9. I am creating a new program using Program Enrollment, and the users only need to log into our Terra Dotta site for this program to complete a questionnaire. Should I create a new custom group, or should I add these users to the Application Manager group?
It would be for you to decide what permissions you want users to have. It is not required that you use system groups, so you can always create a custom group if that better suits the access needs of a group.
10. I have a situation where each member of a group is only responsible for managing updates to their respective program, and I want to set a program restriction for each group user on an individual level. How do I add a restriction to an individual user?
If you have a situation such as this one where you need to add a restriction at the user level, then navigate to the "Users" section. After you search for and locate your user, click on the edit pencil. From the "Edit User" page that appears, scroll down the page and click on the "Show Advanced Settings" link. This will expand the section from which you can add an individual restriction.
11. If I need to create a new staff member, how do I do this in User Management?
To add a new user to your Terra Dotta site and create a user ID for them, you will want to use the "Create User" option in the "Users" section.
12. What is the difference between a restriction and a visibility option?
A restriction limits what applications a user can see, and a visibility option limits the data that a user can see in those applications. See the section on "Restriction and Visibility Options" in this article for full details.
13. In the past, we used Maintenance > Edit User to reset the password of a non-integrated user. How can these passwords be set since this is not an option in User Management?
With the use of the Login, a non-integrated user is able to reset their own password by clicking on the "Forgot Password" link. This eliminates the need for them to contact an administrative user to perform this action on their behalf. See the "Resetting a Password" section of The Login article for full details.
14. We have one questionnaire to which we only want a few people to have access. Is there a way to grant this access other than giving everyone else access to every other questionnaire besides this one in the visibility section?
At this time, there is not.
15. What is the logic for multiple restrictions? For example, if we have a program group restriction and include an applicant parameter restriction, what will users be able to see?
Restrictions are additive, so your users will see applications for programs in the selected program group. They will also see applications for any applicant who has the an applicant parameter of the designated value. See the "Restriction and Visibility Options" section in this article for full details.
16. I have 10 faculty members assigned to the same group because they all need the same set of permissions; however, each faculty member should each only have access to certain program applications. What should I do to make this happen?
You should not set any group-level program restrictions. Instead, this should be done at the user level for each faculty member. This is because restrictions are additive (as noted in FAQ #15). If someone is a member of a group with X restrictions, then those restrictions will remain true for that user as long as they are a member of that group. If you make edits to restrictions at the user level, this action will not impact the restrictions assigned at the group level.
Overall, a restriction will not be removed from a user if that user is in a group with the same group-level restriction assigned.
Let's imagine that faculty member Susie is in your Faculty Leader group. If you were to set a restriction at the group level to all programs in "Program Group A", then Susie would only be able to see applications for programs in Program Group A. If you then attempted to further restrict Susie's access by unchecking some of the programs from Program Group A under the "Restrictions" tab at the user level, then this action would only impact Susie's user-level restrictions. All of the group restrictions would still be applied for the Faculty Leader group - and since Susie is still a member of that group, she would still have access to all programs in Program Group A. The better option in this example would be to remove all group-level restrictions from the Faculty Leader group and leave the restriction configuration set to "Access to All Applications". Then, you would edit each user's restrictions at the user-level.
17. How do I search for an integrated user to add them to a user group?
There are two specific user-search scenarios that are possible:
- Integrated User with No Terra Dotta User ID
If you have an integrated user who has never had a user ID created in your Terra Dotta site, then you will want to navigate to the "Users" section and click on the "+" icon to "Create User". From the "Create User" page that appears, you will want to use the Directory Lookup field to search for your integrated user as this field pulls from your SIS/HR file.
- Integrated User with a Terra Dotta User ID
If you have an integrated user who already has a user ID in your Terra Dotta site and you want to add that user to a group, then you will want to navigate to the "Groups" section, locate your desired group, and click the edit pencil. From the "Edit Group" page that appears, navigate to the "Users" tab and use the "Add User to Group" field to search for your user. This field is going to pull from anyone how has a user ID in your Terra Dotta site.
18. If you use a SIS file, would you then use the UUUID to get the integrated user?
Yes, the username field is the UUUID of the user in the SIS data source.
19. How can you change a non-integrated user to an integrated user?
From the "Edit User" page in the "Users" section, you can change the integrated flag of the non-integrated user and then change their username to the UUUID in the SIS data source.
20. Should accounts only need to be registered by persons outside of your organization?
Yes, non-integrated users are the ones that will be completing the registration form where they fill out their details and create a password. Integrated users will not need to do this as they will log into the site using their SCL credentials. Their user data is populated from the SIS data source.
21. Do we need to use the "Invite User" process, or can we simply add users to a permission group from the "Groups" section?
It is completely optional to use the "Invite User" feature.
22. What should I do if I need to modify a system group's permissions?
A system group is hard-coded, so the assigned permissions cannot be changed. The option to create a custom group with the desired permissions is always available.
23. I've added a staff member to a permission group, but they cannot see anything when they log into their site. What might be causing this?
Most users have two accounts in a Terra Dotta site: an integrated and non-integrated account. Sometimes an admin will accidentally add the wrong account to the permission group. For example, if Susie's non-integrated user account was added to the System Administrators group, yet Susie logs into your site with her integrated user account, then she will not benefit from the permissions assigned to the System Administrators group. As the admin, you would need to remove Susie's non-integrated user from the group and add her integrated user account instead.
24. Are users able to edit their own permissions?
Yes, in User Management, a user is able to edit the permissions to which they've been assigned.
25. I have several users in a group who are reporting that they cannot access any applications. What might have happened?
Navigate to the group and check the restrictions. It is likely that someone selected the option of "Access to Assigned Applications" in error. This restriction option tells the system to only allow users in the group to see those applications to which they've been assigned via the use of the Application Created Trigger. We suggest selecting the option of "Access to a Subset of Applications" if you need users in the group to only have access to specific program applications or those with specific applicant parameter values.