As of July 12, 2021, this "Learn Veracross" site has been deprecated. It will remain live at least through July 2022, but will no longer be updated. All knowledge content has moved to the new Veracross Community. Please update your bookmarks.
Development offices often define constituent roles in a different way than the rest of the school might classify constituents. For example, admissions and academics might consider Parents of Former Students and Parents of Alumni separate roles but Development may want to combine the two groups into one role called “Former Parents.”
For this reason, Development has a separate set of roles that can be configured for reporting purposes. Typically these roles are used as the basis for the common report “Giving by Role”, where each donor is put into their appropriate role to get a summary view of giving for each constituency group. Giving by Role* can be reported on in two ways:
1) Summary of giving by role with constituents included in each role they belong to (which means the giving amounts and constituents will be double counted when donors have more than one role).
2) Summary of giving by role with constituents included only in their primary role, according to the hierarchy the Development office has predetermined.
The documentation below outlines how to create and define Development roles to be used for both of these reporting purposes.
Development Roles can be created and defined using the Development Roles link under Configuration on the Development homepage.
Adding New Development Roles
To add a new development role, hover over the Add button on the Development homepage and select “Development Roles”. Create a description for the role, associate it with the proper role category (usually “Default”) and click “Add Development Role.”
Defining Development Roles
Each Development Role can be defined by selecting the appropriate Development Classifications that should be included in this role. Typically the classifications with a type of “Person Roles” or “Organization Roles” will be the ones used to define these roles. This allows multiple Person Roles to be identified and grouped together within one Development Role. For example, a school might create a Development Role called “Friend” where Former Staff/Faculty and Former Board members are chosen as the Development Classifications that will make up/define the “Friend” role.
It is important to note that often times schools will have 5-10 defined Development roles, one of which ends up being “Other” (or something similar) which is intended to be a catch-all for anyone who does not fit into any of the other roles defined. For a role of “Other”, schools should use the classification called “Other Donor” which captures anyone who does not fit into another development role defined by the school.
In order to create reports where constituents are not double counted in the multiple roles that they are part of, Primary Roles are assigned to giving history records based on the hierarchy setup by the Development office.
To configure the hierarchy for the defined roles, set the Sort Key on the Development Roles report under Configuration on the Development homepage in the proper hierarchical order. For example, the hierarchy on the Development Roles might be:
With this hierarchy setup, if a household has members who are both a Parent and an Alumni, they will belong to the Parent role when running a report by Primary Development Role* because the Parent role has the lower sort key value.
*To learn more about how to create the role reports mentioned above, see the documentation on creating Summary Reports.
Multiple Role Categories
At some schools, there is a need for multiple role hierarchies for different reporting purposes. For example, some schools have a role hierarchy used for internal reporting for the Board (e.g. where Alumni is the highest level), but need a different role hierarchy for sending a report to NAIS (e.g. where Trustees are the highest level). It is possible to create multiple role hierarchies in Veracross by tagging each role with a Category. The main set of roles should use the “Default” category, but other roles can be added to different categories as needed to allow for easy creation of alternate role summary reports.