Coalitions Limitations

Here are the places where the “walls” do not go all the way to the top in a shared database, even when the Coalitions module is turned on and set up fully. The client option “orgcamps” needs to be set to achieve maximum data and functionality separation.

Meetings module: all coalition users share the same meetings setup/edit functionality. Separate online calendars can be created by TDB staff and will use the Meeting Type field to designate which calendar a particular meeting should be shown on. When setting up a meeting, all coalition users will see a meeting list that contains ALL meetings and be able to edit ALL meetings. It is also possible to set up a meeting and cause it to appear any coalition calendar by setting the meeting type. In addition, if a meeting is NOT given the correct meeting type, it will not show up on a coalition designated calendar.

The “god” user: All databanks must have 1 user that can see ALL contact records. This top level administrator can create new coalition organizations and users. This user also should/could be used to merge duplicate records. The god user cannot CREATE action alerts. This is because the action alert system knows how to brand an action alert based on the coalition org’s ID in thedatabank. Once an alert is created by a coalition user, the god user can edit and send an alert.

Custom tables: If Coalition partners share the same custom table, they will be able to see/change/delete data entered into this table for a contact record by another coalition partner–assuming that contact record is associated with both coalition groups. This can be prevented by keeping separate contact records for each coalition group (ie, never merging duplicate records). This can also be managed by created separate custom tables for each coalition group. Custom table access can be limited by user permission.

Relationships: The relationship type and role are shared among all users, regardless of their coalition affiliation.

Subscriptions: All coalition users can see all subscriptions setup up in a databank. If a user has read/write/delete permission for the subscriptions table, they can alter any of a contact’s subscription data.

Publications: All coalition users with Setup permission can see/edit the Publications page which contains all publications for all coalitions. Thus, it’s possible that they’d change or delete a publication that belongs to a different coalition partner. Creating a publication does not make it show up on any online forms. To make a publication show up on an online form, the user needs to use the Form Builder tool to assign a publication to an online form.

Standard drop downs: such as Activity Type, Activity By, etc are shared by all users in a databank so all coalition partners will see data values created by other coalition partners. Similarly, in the case of the Activity info, a user with Setup menu permission could remove activity type/by values by using the Data Clean Up tools.

Shared personal table fields: If a client chooses to customize personal table fields and make them available to coalition level users, there is no ability to create a separate data value list for each coalition partner. Personal table fields should be used for data in common for all coalition partners. Any data that is not shared by all coalition partners should be contained in custom tables.

Saved Search lists: all users can see Saved Searches where the “Allow other users to replay this search” box is checked. Search results will only return contacts who belong to the Coalition partner’s data set.