Learn how site administrators can create new user accounts, deactivate existing users, add or edit user roles, and manage permissions.
Managing Users
Navigate to Admin Tools & Settings, then select Users from the 'Users, Roles, and Permissions' section.
In this section, site administrators can add, edit, or deactivate GivingData users.
To edit or deactivate a user account, click the yellow edit button to the left of their email/username.
Within the Edit User modal, site administrators can edit the user's basic information, edit the user's permission role, or deactivate the user account.
Deactivating a user account will discontinue their access to GivingData. Deactivated user accounts can be made active again at a later date if needed.
To add a new user account, click the green Add New User button toward the top of the page.
If your organization migrated from a previous grants management system (GMS), you will first be asked if the new user had an account in the former GMS. If the answer is yes, select the user from the list of accounts migrated from the former system. This will link the activity logged to that user in the former system with their new account.
If the answer is no, you will be taken to a modal to create a brand new user. Below are the options available for adding a new user:
The user's name, title, and phone number can be included as fields within a Microsoft Word template, email, or SuperDoc.
- Account Inactive - For new users, leave this box unchecked.
- Site Roles - This is where you assign which permission role(s) the user should belong to. A user can belong to more than one role. It is important to note that the more permissive permissions will override more restrictive permissions. For example, if a user is in the Program Staff role, which cannot manage payment information, and is also a member of the Finance role, which does have the ability to manage payment information, the user will have the ability to manage payment information.
- Default List View Record Count - When viewing lists of records in GivingData (such as Super Search results), this determines the default number of records the user will see on a single page. The options are 5, 10, 25, 50, and 100.
- Show in Staff List - Checking this option means the user will appear in lists of staff wherever they are available. This means that they can be assigned as primary or secondary staff on requests, assigned as followers on a request or Grantee Portal intake entry, can have workflow tasks assigned to them, or can be added to interactions.
Managing Roles & Permissions
To manage user roles and their permissions, select 'Roles & Permissions' from Admin Tools & Settings. On this page, site administrators can create new roles, modify the permissions of an existing role, or delete a role.
To add a new role, select the green 'Add New Role' button. To edit an existing role, select the pencil icon beside the role's name.
Within the modal, site administrators can add or modify which permissions the role should have by selecting the checkboxes beside each permission.
Please note that the checkbox for "Role can view data in GivingData” must be selected or else users in this role will only see a blank screen when attempting to log in.
Not all sections of permissions may be present in your instance of GivingData. The available permissions are dependent upon the GivingData features available with your subscription.
Some elements of GivingData have just one permission option called “Manage.” If a feature or action only has "Manage" as an option, this means that granting the "Manage" permission will allow users with this role to add, edit, or delete. It also means that the element of GivingData is viewable to all users logging in to GivingData.
For example, the “Manage Organization Notes” permission means that all users with a login can view Organizational Notes, even without this permission. However, only users with the "Manage Organization Notes" permission will be able to edit or delete organization notes.
Some features may have a separate "Delete" permission. If you see this, that means the "Manage" permission for that feature includes viewing, adding, and editing. In these cases, the user must have a separate delete permission in order to delete. For example, see the Manage Organizations and Delete Organizations permissions.
Some elements of GivingData also have separate “View” permission. This means the “Manage” permission will only control adding and editing that element of GivingData. A user must also have the "View" permission if they are to be able to see that element of GivingData. For example, see the permissions for View Organization Documents, Manage Organization Documents, and Delete Organization Documents.
Admin Tools & Settings Permissions
While editing a role, site administrators will notice a section for "Admin Tools & Settings Permissions". This is the area governing access to system settings. If a role has permission to access one or more sections of Admin Tools & Settings, they will see the gear icon within the quick navigation menu.
The sections within Admin Tools and Settings are:
- Organizations & People - Options to manage settings for Organizations, Contacts, Interactions, and (if applicable) the Grantee Portal
- Grantmaking - Options to manage settings for Requests, Payments, Requirements, and (if applicable) Workflows, Monitoring & Assessments, Dockets, and Portfolios
- Documents & Templates - Options to manage settings for Documents, Super Docs, and the batch email functionality
- Tags & Coding - Options to manage tag and code settings
- Search, List Views, and Reports - Options to manage Super Search settings, Default List Views, and Report settings and templates (if applicable)
- Users, Roles, and Permissions - Options to manage users and roles
- System & Setup - Options to manage Fiscal Years and the site logo and branding colors.
- Activity Logs - Provides access to GivingData’s Activity Log search, site-generated email log, and user logins log.
Site administrators can allow users access to specific sections of Admin Tools & Settings, but cannot get more granular within that area. For example, if a role is granted access to the Grantmaking → Requests permission, the users in that role will have the ability to manage all settings within that area, such as Request Statuses, Transaction Types, Declination Reasons, Default Coding, etc.
Permission should only be granted to a role if it is acceptable for those users to have access to all site configuration options in that section.