Migration Overview

When you log in to the Users page for the first time, notice all users at your organization appear under Users. You now manage all of your organization's users with a Blackbaud ID in this same location. In addition, inactive users appear in this list.

Existing non-admin users automatically have access to feature areas based on their migrated roles. No additional action is needed on your part.

Note: By default, only users with Supervisor rights selected as a group assignment in the database view have access to the Users page. Users with Selected group rights selected— even those with rights to Administration, Users in the database view through their security group – do not. To provide access for these users, select Make admin from their manage roles page.

When you save a new user with assigned feature areas and roles, they receive an email invitation they must accept to begin working. Existing users have access without accepting an invitation; no invitations are sent during the migration.

Like security groups, a role allows access to permission-based tasks in a feature area. Roles couple tasks and permissions to determine a user’s access to a feature area.

Note: The feature areas that a user has access to appears in their navigation.

To provide a smooth implementation, security groups with active users that have rights to web view features have been migrated to roles. To easily identify these roles, their names and descriptions capture the web view security groups used to create them.

• Most groups with rights set for web view features now appear as identical roles, with the group's rights now its corresponding role's permissions.

  For example, Bob and Shirley were assigned to security group A with rights to features X and Y in the web view, and Jane has security group B with rights to Z in the web view; Bob and Shirley now have events role A with permissions to X and Y, and Jane has events role B with permissions to Z.

• For more nuanced users, security groups with rights set for web view features may combine into a single role to capture rights that don't align with the same tasks and permissions of other roles created from security groups.

  Following the example above, Jill was assigned both security groups A and B in the web view; her new fundraising role is 'A & B' with permissions to X, Y, and Z in the web view.

Note: Only security groups with rights set for web view features appear as roles. In the database view, you can manage security groups to secure database view features and determine which data users can access, such as to secure donor information by constituent code or gift information by fund.