Branch Security module

You can't edit or view data from other branches unless you're granted permission to do so. In addition, your reports and searches only include data for the branches for which you have “view” rights.

To accomplish this, you can enter a code for each of your branches into the system. Each Request and its associated Activities, Payments, and Requirements are then stamped with a primary branch. Each group’s access can then be restricted to records based on the branch stamp.

Note: Access to Organization and Contact information is not limited to specific branches. This ensures that you maintain an accurate giving history for Organizations that are funded by more than one branch.

When you set up Branch Security for your system, you must choose one of two ways Requests (and thus their associated Activities, Payments, and Requirements) are stamped with a primary branch:

• A Request is automatically stamped with the primary branch of the user creating it.

• The Request form can include a branch field, permitting a user to enter a specific branch.

The option you choose depends on which of two different data entry models you use.

The centralized data entry model is most likely to be used by organizations that manage several different, wholly separate funds.

In this case, a single user group is accepting, entering, approving, and declining grant requests for many various funds. However, you want representatives of the individual funds to be able to view the data for their fund (and their fund only).

In this case, you want your users to enter the branch for each Request manually. This permits a single user to enter Requests for several different branches.

For example, you could create a “Headquarters” branch that has access to all data; these users would be employees of your central organization. Then you can create a branch for each fund you represent, adding the fund’s representatives to the appropriate branch.

Your users assign a branch to each Request they enter, depending on the specific fund being appealed to. Representatives for each fund (or “branch”) are then able to access data concerning their fund only.

When following this model, the branch must be entered in each new Request manually. You are not permitted to save a new Request without entering a branch. The branch field appears in the Request form only if you choose this Branch Security option.

The branch field may appear on the following forms when using this Branch Security option:

• Activities: If you are creating a new Activity not associated with a Request, the branch field appears. If you create an Activity associated with a Request or Payment, the Activity is automatically stamped with the Request’s (or the Payment's Request's) branch, and the branch field is unavailable.

• Budget Items (Categories, Line Items, and Reserve Funds): In the Budget, an editable Branch field appears on new budget items, if those items are children of first-level Categories. You can select the branch for top-level Reserve Funds. Children of each second-level Category all have the same Branch, which can't be edited.

This data entry model is appropriate if members of your various branches or divisions are receiving, entering, approving, and declining grant requests more or less independently of one another. Your data is all stored centrally; however, each branch or division works almost exclusively with Requests and grants that they have entered themselves.

For most foundations and corporations with branches or divisions, this is the model they follow.

In this case, you would want Requests to be automatically stamped with the primary branch of the user creating it. This enables members of each branch to enter Requests (and other associated records) that can only be viewed or edited by other members of the same branch.

If Grantmaking includes the optional Annual Budgets feature, budget items must still be stamped with a branch manually, as described for the centralized data entry model above.