Securing Contributor Relations

This chapter discusses how to:

• Set up Institution table security.

• Define and secure Contributor Relations business units and setIDs.

See Also

Setting Up Your Contributor Relations Framework

Setting Up Institution Table Security

To set up institution table security, use the Academic Institution Security component (SCRTY_TABL_INST).

This section discusses how to set institution table security.

Page Used to Set Up Institution Table Security

Setting Institution Table Security

Access the Academic Institution Security page.

Academic Institution

Provide the user with access to the system for that institution. When entered, the user automatically has read/write access to all the data related to that institution. If a user is given access to only one institution, that institution defaults on all pages requiring an institution.

Defining and Securing PeopleSoft Enterprise Contributor Relations Business Units and SetIDs

To define and security Contributor Relations business units and setIDs, use these components: Business Unit CR (AV_BUS_UNIT), Functional Group Security (AV_FUNC_GRP_TBL), Functional Group Components (AV_CMPNT_FUNC), and Secure Business Unit (AV_SCRTY_BU_TBL).

This section discusses how to:

• Create Contributor Relations business units.

• Implement functional group security.

• Define functional group components.

• Choose component search record settings.

• Secure Contributor Relations business units.

Understanding Contributor Relations Business Units and SetIDs

Establishing business unit structure for Contributor Relations enables you to efficiently secure and segment data. This organizational structure may differ from the structure set up to support other PeopleSoft applications at the institution. You can define business units that reflect the functional needs of the institution, and setIDs for sharing tables with setup values. This structure enables you to define data segmentation based on business rules. In addition query and reporting capabilities become more powerful for the institution and the individual user.

In Contributor Relations, both the membership and commitment entry portions of the system are secured at the business unit level.

In addition, the system is delivered with a set of defined functional groups that represent the business processes impacted by business units. For each functional group, determine whether or not to implement user level security. If user security is selected for any functional group, establish user access to appropriate business units.

Warning! Before creating and securing business units, think carefully about how to set up the institutional structure and about what information particular users need to access. After you define a structure, you cannot delete a business unit to protect historical data related to a business unit.

Pages Used to Define and Secure Contributor Relations Business Units and SetIDs

Creating Contributor Relations Business Units

Access the Business Unit CR page.

Institution	Enter the name of the institution to which the business unit belongs. If you have already saved the business unit, this field is display-only. If a business unit is assigned to a different institution, a new business unit CR should be created.
Base Currency	Enter the base currency to default when entering transactions or working with financially driven Contributor Relations processes within this CR business unit.
Rate Type	Enter the exchange rate to use when translating amounts to the base currency for this business unit. Examples of rate type are Official Rate, Spot Rate, and Free Market Rate. Note. Transactions entered in the system are translated from the session currency to the institution’s base currency using the rate type on the Institution Defaults page. The business unit base currency setting is used as the default currency code for all membership and gift sessions created for a business unit, but can be overridden.
Tender Type	Enter the default tender type to use when entering transactions for this business unit. Tender types are defined on the Tender Types page. The tender type is used as the default tender type for all membership and gift sessions created for this business unit, but can be overridden.
General Ledger Unit	Enter the business unit at the institution where GL data for this Contributor Relations business unit is stored. Tying data to this general ledger unit enables you to structure Contributor Relations business units differently than other business units at the institution. The business units you define are tied back to the general ledger business units through this field.
Merchant ID	To define the credit card merchant information and credit card default options for each business unit, enter the merchant ID from the CR Merchant table. You must associate each business unit with a merchant ID. See Defining Connection Parameters for Third-Party Processor.

Examples

The following scenarios represent two different ways an institution might set up Contributor Relations business units.

PeopleSoft University A is a single campus institution. This institution’s business units are organized along individual schools, with some degree of centralization. Its business units include:

• Medical School Business Unit.

• Law School Business Unit.

• PeopleSoft University Business Unit (Centralized Business Unit for all standard schools. For example, School of Arts and Sciences, School of Business, and School of Education).

PeopleSoft University B is a multi-campus institution, and its business units are organized by its various locations. Its business units include:

• Main Campus business unit.

• Extension Campus business unit.

• Online Campus business unit.

Implementing Functional Group Security

Access the Functional Group Security page.

Functional Group Security Level

Warning! After running the Refresh Security process, you must delete all cache files. You must also re-run the PeopleTools process that creates a shared cache file for multiple application servers. This process impacts all applications sharing this database! Contact your IT Support Staff before running this process.

Defining Functional Group Components

Access the Component Function page.

Warning! If the security determination process is run on a component that’s not assigned to a functional group on this page, the system displays a warning alerting you to the missing setup values, and the component is accessed without business unit security activated. The system is delivered with all of the appropriate components assigned to their respective functional group. Do not make any changes to these settings unless the institution is adding business unit functionality not provided by Contributor Relations.

Component Functional Group Assignment

Choosing Component Search Record Settings

Access the Component Search Record Settings page.

Warning! The system is delivered with all search views assigned to the appropriate components. Do not make any changes to these settings unless the institution is adding business unit functionality not provided by Contributor Relations.

The following components are secured at the search view level:

Securing Contributor Relations Business Units

Access the CR Business Unit Security page.

Business Unit	Enter the business unit for which you want to grant the user access.
Access Code	Indicates the type of access a user has to a particular business unit. Since security is granted when you add a row to this table, this field displays a value of Read/Write.

Understanding Business Units and the Commitment Entry Process

The following process describes how business units work within the commitment entry process. This process assumes that you have already set up an operational structure, including business units and setIDs, and secured them.

To work with business units throughout the commitment entry process:

1. Define setup values for commitment entry.

   These include defining values for designations, initiatives, and appeals.

2. Set up user defaults for institution, business unit, and setID using the Operator Defaults page.

   These default Values are: used throughout the system. In addition, select defaults for designation business units.

3. Open a new gift or pledge session.

   Each session is associated with a business unit. Within the session, commitments can be designated to one or more business units. After a session is established, default designation business units, designation, initiative, and appeal can be defined using the Session Defaults page. These defaults override any user defaults that have been defined. Session defaults can also be changed at any point during the transaction entry process.

See Also

Entering User Defaults

Selecting Session Defaults

Understanding Business Units and the Membership Process

The following process describes how business units work within the membership process. This process assumes you have already set up an operational structure, including business units and setIDs, and secured it. The process also assumes you have defined user defaults and setup values for the commitment entry process.

To work with business units throughout the membership process:

1. Define setup values for membership including appeals, membership types, and membership categories.

   See Setting Up Membership Initiatives.

2. Create a member organization within a business unit.

3. Define member dues for the member organization.

   When defining dues, specify default designations to which dues payments are allocated. Select a designation business unit, designation, initiative code, and amount for each designation to which a portion of the dues payment is allocated.

   See Creating a Member Organization.

4. Create a membership initiative. Select a business unit to associate with the membership initiative.

   This “owner” business unit controls the available prompt values when selecting a responsible department, selecting an associated member organization, defining annual goals, selecting a public relations appeal, and selecting an appeal for a budget expense.

   See Defining an Initiative.

5. Receive a membership payment/open a membership session.

   Select a business unit for the session. When you assign membership dues designations, the values defined on the Member Dues page populate the fields on the Designations page. You can edit the Initiative and Amount fields.

   See Entering Member Dues.

Contributor Relations Business Unit Security and PeopleSoft Query

Business unit security is applied to functional groups within Contributor Relations through a user-defined setting based on components not records. Therefore, it has not been applied to PeopleSoft Query. Contributor Relations records are delivered in the system without a Query Security Record attached, but an example of how you could extend business unit security to PeopleSoft Query is provided.

It is important to remember that there are two ways of using business units within Contributor Relations.

The first is the business unit owning the transaction (such as gift, pledge, member payment), and the second is the designation business unit or the business unit to which some portion of a transaction amount is directed. The first is represented by the BUSINESS_UNIT field throughout the system, while the second is represented by the AV_DES_BU field. In most cases, business unit security is applied to the AV_DES_BU field throughout the system when invoked. There are, however, some cases where the business unit security setting is applied to the owning business unit as opposed to the designation business unit. When designing queries and query security records, deciding where to apply the security affects which query security record is used and what data is returned. If securing by owning business unit, the query security record AV_BU_SCRTY_VW is used, and if securing by designation business unit, the query security record AV_BU_SCRTY_DES should be used.

Applying security to both business unit types in a query most likely does not produce the desired result. For example, take an installation that has three business units BU1, BU2, and BU3. A gift is entered by business unit BU1 and some of the gift is directed toward a designation fund in BU3. A user exists who has security access to see the gift information for BU3 only. If query security is applied at the owning business unit level, the user is then prevented from seeing that portion of the gift directed to their business unit. If both owning business unit and designation business unit security are applied in a query at the same time, the owning business unit application prevents the designation business from even being considered. If the query security is applied at the designation business unit level only, the user can only see that portion of the gift that was given to their business unit.

Examining a Query Security Example

There are two methods for applying business unit security to PeopleSoft Query:

• Using the PeopleTools Query Security Record function and one of the delivered Business Unit Security records (AV_BU_SCRTY_VW and AV_BU_SCRTY_DES).

  Use this method to provide records for which the user population can create queries that are automatically secured by PeopleTools.

• Using a subquery and the query metastring %OPERATORID.

  Use this method to develop queries (or Query/Crystal reports) that are created centrally for the user population but available for users to run on their own.

There are three delivered queries provided to illustrate the two methods:

• AV_SECURITY_EXAMPLE_NONE

• AV_SECURITY_EXAMPLE_SECURED

• AV_SECURITY_EXAMPLE_SECURED2

Unsecured Example

The query AV_SECURITY_EXAMPLE_NONE is an unsecured query of Recognitions with the following criteria:

• Credit type Hard.

• Person recognitions only.

• Posted.

• Not adjusted.

• Institution equal to PSUNV.

The result of this query is the data to which the query security is applied in the next two examples. To see the impact on the query results with each type of setup, run the query as a user with access to all business units then as a user with access to only one business unit.

PeopleTools Query Security Record Function

The next query, AV_SECURITY_EXAMPLE_SECURED, includes a record, AV_RECOG_SEC_VW that has a security view attached to it via the Query Security Record attribute. In this case, the Query Security Record is AV_BU_SCRTY_DES. This record is a view of PS_AV_SCRTY_BU_TBL substituting the AV_DES_BU field for the Business Unit field. When a record has a Query Security View attached, PeopleSoft Query automatically adds a filter of {Security_Record}.OPRID = %OPERATORID. At run time, the %OPERATORID string is substituted with the user ID of the current user. PeopleTools also joins the record and its Query Security record by other common keys. In this manner, the user only sees the AV_RECOG_SEC_VW records to which they have security.

With the same data set and a user who only has access to the business unit MEDBU, the results are as follows (notice the absence of any data for the PSUNV business unit).

Using a Subquery for Security

The final query, AV_SECURITY_EXAMPLE_SECURED2, is similar to the unsecured example above in that it uses the base unsecured tables. In this case however, a subquery is added to provide the join to the Business Unit Security table and only return rows to which the current user has authority. Because security is applied to the designation business unit in this example, the record AV_RCG_DES is substituted for the record AV_RECOGNITION from the unsecured query. The field AV_DES_BU is now available for applying the query security. The subquery appears as a filter on the AV_DES_BU field when the Criteria tab is selected. The subquery uses the AV_SCRTY_BU_TBL and criteria of OPRID = %OPERATORID to substitute the user ID of the user currently executing the query.

With the same data set and a user who only has access to the business unit MEDBU, the results are as follows (notice the absence of any data for the PSUNV business unit).