What Are Databank Coalitions?
Coalitions s a way to segment your Databank into different subsets of contact records and data based upon their affiliations and identifications.
With coalitions enabled, an individual Databank user will only have access to the data which they are affiliated. This means that if your organization has both a c3 and a c4, the only records visible to a user logging as part of the c4 are the records affiliated with the c4.
Your organization may have any number of subsets or coalition partners with which you work. This document will be using the example of an organization with a c3 and a c4 to illustrate the process, but it can be any designation you choose. |
How do Databank coalitions work?
Essentially, we have a little bit of extra data (metadata) which affiliates a member and their activities to the different subsets you have defined. The first thing we do is create “organizations” in your Databank. This is what defines the subsets and assigns the metadata, which we call the Organization ID, to each organization. If you already have a database full of individual contact records, we will work with you to identify which records belong to which organization.
Also, individual contact records in your Databank do not need to belong to only one Organization. A record can have both the c3 and c4 designation and belong to both of your Organizations.
When a contact record is in both your c3 and c4, the data associated with them is split into the subset as well. This means that an individual would have some PowerMail issues from the c3 and some from the c4, as well as donations and contacts for each Organization.
Your Databank |
What does that look like for Databank users?
The Organization ID metadata is applied to Databank Users as well as to the Contact Records. This means that a user who has the c4 Organization ID will only see c4 data, and a user with the c3 Organization ID will only see the c3 data. This does not mean that your users can only be involved in one organization or the other.
Similar to the way that a Contact record can possess multiple Organization IDs, a Databank User can be associated with multiple logins, each one having a different Organizational ID. Using the login switcher, one User can switch back and forth between different Organizational logins. There is also a “top-level” administrative user login which has access to all the data associated with that record, regardless of which Organization ID the contact record has.
A Top-Level view of a Contact Record’s History versus a c3 level view of the same record |
Top-level View |
C3-level View |
How does this change our workflow and processes?
For most organizations and most Databank users, this will not change your workflow that drastically. But for some, it may create a change.
If your Databank user is someone who works exclusively with either the c3 or c4 records, barely anything will change for them. In fact, their work may be easier because they no longer have to make sure to remove ineligible contact records from their selection using queries or accidentally sending an email to the wrong subscription list.
For Databank users who work with both types of records, they can easily switch back and forth between their different Organizational logins using the login switcher in their profile.
For de-duplicating your Databank and doing general maintenance, the Top-Level login is the preferred login to use. For all other activities, such as creating PowerMail issues, recording donations, and creating forms, the Organizational logins are recommended. This is because every action in your Databank taken by a user who has an Organizational ID will have that same Organizational ID attached.
Summary
In summary, using coalitions in your Databank is the best way to ensure organizational compliance with keeping your records segregated without the burden of having to maintain multiple databases.
Comments
0 comments
Please sign in to leave a comment.