Why roles & authorizations matter
Whenever you log into a web-based application to perform payroll, financial reporting, human resources activities, or other administrative tasks, you draw information from secure databases created and maintained by a variety of MIT entities. Not surprising, direct access to these databases is very limited, but such restrictions are essential to protecting the integrity of the data and the privacy of personal information.
What data and applications you can access depends on the rules or privileges you are granted through a system of roles and authorizations known as the Roles Database. If you have just assumed an administrative role, have new administrative responsibilities, or simply want a better understanding of how roles and authorizations work, this “how to” is designed to give you an overview and connect you with important resources.
Users—how to get access
The Roles Database contains authorizations—rules about people’s roles or privileges —for MIT’s financial and other business systems such as SAP. Authorizations are maintained within the Roles Database by staff at the central and departmental levels. The Roles Database does not enforce the authorizations that it contains; it simply collects authorization information and distributes it to the appropriate applications, typically as a nightly data feed. Applications that interface with the Roles Database interpret and enforce the access rules stored in the database.
If your job responsibilities require you to use these or other administrative software programs, a “primary authorizer”—the person responsible for granting individual authorizations within a DLC—must designate you as an authorized user on the Roles Database.
If you lack access to a software application you believe is essential to one of your roles, you should contact a primary authorizer within your department, lab, or center. Primary authorizers are typically central administrators, administrative officers, or assistant deans.
Authorizers—how to use the roles database
As a primary authorizer, you can log into the web-based Roles Database application using Touchstone or your MIT Kerberos name and password. Once there, you can
- look up existing authorizations
- create and delete authorizations
- get specifics about each authorization
- copy or reassign authorizations
- change expiration dates of authorizations
- customize your Roles Database starting screen and much more
Sample roles & authorizations
“When it comes to roles and authorizations,” says IS&T Central Authorizer Peggie McGrath, “there’s no template or one-size-fits-all. Even when a new employee is taking over responsibilities previously handled by another staff member, it isn’t normally appropriate simply to transfer authorizations to the new person.”
The following scenarios, however, can serve as examples of how to think about recognizing roles and granting authorizations:
Requisitioner or Credit Card Verifier
If a staff member is assigned the role of Requisitioner (i.e., creating internal or external requisitions) or Credit Card Verifier they must also have a Can Spend or Commit Funds authorization for the cost object or funds center you wish them to use.
To enable a staff member to approve requisitions, you would grant an Approver authorization. Before you can take that step, however, you need to know your DLC’s release strategy—the set of rules for approving the release of funds. If you don’t have that information, you can find it by going to rolesweb.mit.edu, selecting “tell me about a cost object,” and entering your cost object. You’ll find your release strategy listed under “miscellaneous.” Review MIT’s list of sample release strategies.
Some Approver authorizations come with limitations. Concur Travel Approval, for example, can only be given to one staff member per cost object or funds center. If the authorization is given at a cost object level, the person with the authorization at that level will be the approver. In cases where there is an approver by fund center, that person will be the approver on all cost objects within the fund center and only needs authorization at the fund center level.
Reporting by Fund/Fund Center (FC) or Reporting by Cost Object/Profit Center (PC)
When granting authorizations for reporting roles, it is important to understand the difference between these two types of access. Reporting by Fund/FC only gives authorization for a specific cost object or fund center. Reporting by CO/PC, on the other hand, authorizes reporting on a parent cost object and all of its child accounts, even outside your department.
For either of these authorizations, if you want to allow access to salary subtotals, you must grant See Salary Subtotal in Reports. This is a one-time authorization, and it works with all costs objects authorized for reporting.
On all authorizations you have the option of customizing start dates and expiration dates. Even before someone begins a new role, you can grant an authorization with the appropriate start date as soon as that employee has a Kerberos name. Similarly, you can set expiration dates for new authorizations that are needed only for a limited time frame—for example, when an individual is assuming a role temporarily during a vacation or medical leave.
Primary authorizers should reach out to Peggie McGrath when in doubt. Send your questions and authorization requests to email@example.com.
- Review IS&T’s introduction to roles and authorizations
- Read “Web-based Roles Application for Primary Authorizers”
- Contact IS&T for assistance with the Roles Database