Designing a sustainable security model in Blackbaud CRM may appear intimidating - with the capability to apply permissions globally and granularly, security roles can quickly get out of hand. Here’s a way to break it down, if you are considering streamlining your existing security model, or if you are implementing CRM for the first time:
View - Edit - Delete:
Blackbaud CRM™ security, by default, denies-all functionality until a System Role is applied to the individual user. This means, users will be able to login, but will not see any functional areas or pages until they are assigned at least one System Role.
Start with identifying the pages and functions that every user will be able to see (for example, the Constituent Page, or the Revenue Transaction Page)
For those, establish a “View Only” System Role - now your users will be able to search for Constituents, and navigate to the Constituent page.
Next, consider which users should have permission to Add or Edit records on those pages - Bio/Records staff may have permission to edit the Constituent page, but not the Revenue page, while Gift Processors will have access to edit transactions.
For these users, establish System Roles for “Administration” or “Edit”.
Certain users will have access to delete items from the database - those users should have a “Delete” role as well, if it has not been included in the Add/Edit role.
Feature Permissions:
After creating base System Roles for View - Edit - Delete functionality, you may find a need to apply permissions to specific pages, reports, tabs, or attributes in the system. Often, organizations will restrict access to the Information Library, to only staff who have been trained in Ad-hoc Query creation, for example.
Identify the areas of the system which require more specific security access - Information Library, Major Giving Management, My Prospect Research Page, Constituent Wealth and Ratings page, etc.
Create more job-specific System Roles in CRM to allow View - Edit - Delete permissions in those areas.
Managing Users:
Now that the roles have been defined, assigning users to each role (and managing any personnel changes) can be a daunting task. Organizations have explored (and implemented) different ways to handle this:
Manually assign roles to individuals, based on the tools they need to do their jobs, regardless of their title or organizational structure - this is the most flexible way to maintain security in CRM, but requires frequent attention and management.
Assign roles based on job title or organizational unit - this is still manual, but a bit more structured than assigning roles individually. Assigning Security Roles based on a user’s organizational unit, or job title, streamlines the management of the roles, but does not allow for nuance in job responsibilities. You may find that your design uses this in hybrid with manual assignment.
Sync with your active directory - this is the least flexible, but by creating active directory groups like "fundraiser" and adding CRM System Roles to these groups, any changes in the AD will sync with CRM security. The AD group idea works but can be a little restrictive. For example, you might have a particular fundraiser that you want to give additional rights to (such as Events or Query), but you don't want all fundraisers to have that extra access. The solution to individually add the person to a role is against the concept of AD groups, so the question becomes: how often do you want to make these exceptions? There are always going to be exceptions if you do it this way, because one shoe doesn't fit all scenarios.
Stacking or Nesting Roles: You might also consider “stacking” roles in any of the scenarios listed above. For anyone working in Records and Gifts for example, there may be a number of different roles according to seniority; you may create a base role which nests inside a more advanced role, or layer roles to support a specific workflow.
When considering which method is going to work for you, think about how you are going to know which tasks to assign to each individual. There may not be an easy answer to this question. Are you going to rely on the hiring/direct-report manager to decide what access the new employee will need, or is there a standard job function formula to work to? Additionally, how are you going to handle removing access to the system when the employee leaves? With the active directory idea, that person is removed from their security group as soon as the IT department removes them from AD. However this “easy in and easy out” solution, may bring you back to the earlier question of whether this method is flexible enough for your needs.
After your Security design is complete, it is important to test the roles; testing is an iterative process. Start by assigning a user or two to each System Role and run-as that user. Some iterative “tweaking” will be necessary to ensure that the user can see and do all the functions his/her job entails. Don’t worry if you don’t permission every button, link or page the first time round. System security is something that you are going to need to develop and maintain over time. There will always be new functionality, new pages, reports, smart queries etc. that you will need to add into the mix.