Authority Manager lets you view, grant, and revoke systems authority to persons whose job requires them to access Stanford business systems. You grant a privilege to an eligible person and set scope, limits, and conditions on the privilege. The result is recorded as an assignment. Some privileges have prerequisites (such as training) that the recipient must complete before the assignment can take effect.
Privileges are grouped into business functions, which roughly represent a defined business activity. Business functions are grouped into authority subsystems to help differentiate similar functions.
Each time a grantor goes through the Grant Authority wizard, it results in one new row in the recipient's Person view. Each row represents one assignment. An assignment consists of:
- a grantor
- a recipient
- a business function
- an organization
- a privilege
- none, one, or several limits, depending on how the privilege has been defined
- an expiration condition
- a "grantable" condition (which determines whether the recipient can, in turn, grant this authority)
- a start-date (if specified)
If the grantor selects more than one population, project, task, etc., all the other elements of the assignment apply equally to each of the selections.
For example, if the grantor selects two projects in the same assignment, the same spending limit will apply to both projects. If the projects require different spending limits, they must be granted separately with different spending limits.
A person you designate in Authority Manager to grant authority on your behalf. That person can act as you in Authority Manager to grant any authority that you yourself can grant, but cannot act as you in any Stanford business systems.
Authority subsystems are loosely equivalent to University business offices and the business systems that support them.
- Financial Systems GL — Oracle Financials
- Human Resources — PeopleSoft HR, Workflow
- Student Systems and Data — PeopleSoft Student Admin
In Authority Manager, lists of business functions are grouped by authority subsystem to help distinguish between similar functions in different business areas, e.g., financial approvals and HR approvals.
A set of privileges that represents a defined University business activity.
Examples: Purchasing, Admissions, Payroll
- Financial Systems GL = authority subsystem :. Approvals, Purchasing = business functions
- Human Resources = authority subsystem; Payroll :. Time and Leave = business functions
- Student Systems and Data = authority subsystem :. Admissions, Financial Aid = business functions
An individual must meet specified conditions to have systems authority. They must be a current member of the Stanford community (staff, faculty, student), and must have met any prerequisites attached to the privilege. A manager can set a future start date if they wish to activate the authority later. A manager can also set an expiration date when the authority will be automatically revoked (or renewed by the manager).
Authority can be granted to anyone in the Stanford administrative or academic communities. These include:
- all regular faculty
- all regular staff
- casual/temporary staff
- instructional staff
- department-sponsored IDs (contractors, consultants, temporary help, etc.)
- in some cases current students
If a person has authority, and their status changes so that they are no longer a member of these communities, their authority will be automatically revoked. Only members of these communities can log into Authority Manager to view or grant authority.
The act of assigning authority that you have been authorized to extend to others. You can be authorized in two ways:
- Someone has granted you authority with the "can extend" condition.
- Someone has made you their authority-granting proxy, and they have authority with the "can extend" condition.
Some privileges apply only within the projects, populations, dollar amounts, etc. specified by the grantor — these are collectively referred to as "limits." Some privileges are, by their nature, unlimited.
If a privilege has limits defined, they are displayed in the Grant wizard in Authority Manager allowing the user to make the choices for each limit. Some limits allow more than one selection. All limits require at least one selection.
- Student Systems and Data
- admit center (1 or more)
- item type (1 or more and ranges allowed)
- Financial Systems GL
- project (1 or more; or "all")
- task (1 or more; or "all")
- award (1 or more; or "all")
- principal owner (1 only)
- spending limit (1 only)
Authority Manager sends email notifications to grantors and recipients of authority for various reasons, including:
- new authority granted
- authority limits or conditions changed
- prerequisites to be met, with a reminder after 14 days
- authority condition will expire in 30 days, with a reminder at 7 days
- authority condition has expired
- assignments of authority-granting proxy or acting approver
- reminders when acting approver starts and ends
Wherever possible, notifications of a given type are combined into one daily email. Some situations (such as an acting approver assignment that starts immediately) trigger an immediate notification.
NOTIFICATION FOR REQUESTS
- Authority Manager sends email notifications for different types of authority requests to grantors, requesters, FYI contacts and grantees of authority, including:
- new authority request submitted to copy/edit/revoke
- authority request reassigned to the new approver
- authority request approved/denied
- authority request canceled
Any department or group in the official University structure. All privileges are granted in the context of an organization; a manager can grant authority only within her own organization and its sub-organizations.
Note that the organization applies to the privilege, not the recipient of the authority.
Example: A director might grant some authority for a project owned by her organization to a person in another organization.
Some privileges have requirements (successful completion of training, signature on file, etc.) that must be met by the individual before the privilege can take effect.
When a prerequisite is completed, the individual is added to a special workgroup, and Authority Manager is notified to activate the pending authority.
A specific task or set of tasks that can be granted to an individual. Privileges are self-contained — for example, the "administer leave" privilege covers all the data and tasks required to do that job, in all affected business systems.
|Financial Systems GL||<--authority subsystem|
|: . .||Approvals||<--business function|
|: . .||Labor Distribution||<--privileges|
|: . .||Requisitions|
|Human Resources||<--authority subsystem|
|: . .||Approvals||<--business function|
|: . .||Faculty Affairs Approver||<--privileges|
|: . .||Human Resources Approver|
|Student Systems & Data||<--authority subsystem|
|: . .||Admissions||<--business function|
|: . .||Basic Prospect/Applicant||<--privileges|
|: . .||Enhanced Prospect/Applicant|
The ability to reinstate authority by individual privilege. You can only restore those privileges that you can grant.
The act of removing authority. You can only remove authority that you have been authorized to extend to others.
The organization to which an authority assignment applies.
Access to the portions of Stanford business systems that contain data or tasks related to a specified privilege.
Individuals who have any grantable privilege scoped to Stanford University are system owners for the authority subsystem that includes that privilege. System owners see an additional set of Authority Views on the Authority Manager home page — one for each business function for which they are an owner.