User Overrides are created for individual users whose Web Portal access does not match their default position Role. For example, a school that has a half-time principal might want to allow their secretary to authorize absences. Generally, the role of secretary would not be set-up with authorization permission so a User Override would need to be created here.
Note: Your User Override MUST be named your HR employee number.
Another usage of this function is to create school-based guest accounts that are not linked to an individual. For example, if a casual secretary needs to access AMS Web to review that school's daily absences, they could use a guest account that would show them only AMS Web for that location. To set this up, first the IT department would need to set up a username and password (e.g. u: guest01, p: schoolname) in their Security Database such as LDAP. They would need to assign this user a fictitious employee number like 99999 or G00001. Next you would create the appropriate User Override entry and name it the fictitious employee number.
There are five override options available. You only activate the options you want to trigger the override for. The other information will default to what is obtained during the login Security Check.
Location
-
Enter in the four-digit override HR location number. Separate multiple locations with a comma but no spacing. (E.g., 0024,0045). Location numbers can be either atrieveHR location codes, atrieveHR authorization location codes or atrieveFinance GL selection criteria codes.
Locations can be entered by product license reference.
-
The system will behave in the following way:
-
No Override = HR assignment location will dictate location access
-
Yes Override = With an override, locations can be entered by product: (TEW=0021|0043), (BMW=0001|0002). If a product is not explicitly listed but is available, the location reference will be pulled from the HR Assignment(s).
-
-
If the assigned location needs to be overridden by default, entries can be made at the beginning of the string: 0001, (TEW=0021)
-
Locations listed at the beginning of the override string become the default locations, and the HR location assignment(s) will be ignored. Other product references (products not specified individually) will be overridden accordingly.
-
Products will need to be listed using upper case letters (TEW) with the locations separated by |pipes|.
-
Product-specific location overrides are available for Budget Manager Web (BMW), Req Web (RQW), and Timesheet Entry Web (TEW). All other products will follow the default location security.
Authorizer
-
To activate Authorizer access for an employee, use the Authorizer drop-down menu to select an option:
-
If 'Authorization Enabled' is selected, 'Y' will appear in the Authorizer column
-
If 'Authorization Disabled' is selected, 'N' will appear in the Authorizer column
-
-
Employees can become authorizers by entering a module/product/license reference (RQW, TEW, AMW, etc.).
-
The Authorizer feature in Security Builder can be used to override the Authorizer field atrieveHR via the Position Code Database.
-
Security Checkpoint 2A looks for 'Authorization Enabled' in Security Builder, which will provide the employee with full authorizer access to the modules available, unless otherwise specified in the Custom Field.
-
Products will need to be listed using upper case letters (TEW) and separated with commas. There isn't any validation that occurs in the program, so be careful with entry.
Role Code
-
To enter an override Role Code, use the Role Code drop-down menu to select the applicable role. To remove the role, select 'None' from the drop-down menu, or choose a different role.
GL Security
-
To select GL Security for the User, use the GL Security drop-down menu to select the applicable security. To remove the GL Security, select 'None' from the drop-down menu:
-
Keep in mind that the GL Security is usually applied to a Role. If that Role's GL security needs to be overridden, the template applied to the override record would take precedence.
Employee Number
-
This option will rarely be used. It is needed if the Security Database (Ex. LDAP) that contains the username and password does not also contain the HR employee number of the user. This option can also be used to mirror another employees access for testing purposes:
Possible Reasons for User Security Overrides
-
Example 1- A secretary works at a High School and the decision has been made to allow this secretary to authorize absences. A User Security entry would be made here, setting Authorizer to 'Authorization Enabled'.
-
The Security Check would determine from their HR assignment Position the following:
-
Location = Cedar Elementary School 0012
-
Role = TEAC
-
Authorizer = Blank (No)
-
-
The User Security would override their security access to 'Authorization Enabled' but would not adjust the Location or Role associated with the employee.
-
Reminder: The User Security override must be saved with the HR Employee ID number. This can be found in HR (1,1,4) if unknown.
-
Example 2- A high- level administrator requires full access to all modules and security builder, as well as multiple locations for reporting, authorizing and BMW. This can be accomplished by using the Role Code of full, setting Authorizer to Authorization Enabled, and by entering the necessary locations in the Location Codes field. In this example, 1001- 1003 represent true locations, 2000 represents an Authorizer Location and ALL refers to a GL Selection Code for BMW information.
-
The Security Check would determine from their HR assignment Position the following:
-
Location = Custodial Services 5000
-
Role = ESSFULL
-
Authorizer = Blank (No)
-
-
The User Security would override their security access to include the physical locations 1001- 1003, authorizer location 2000 and BMW GL Selection Criteria of ALL, but would not adjust the GL Security associated with the employee.
Reminder: Each September you should review all User Securities to determine if they apply to the upcoming school year.