Permissions Maintenance

Updated April 29, 2025 16:13

Permissions control the level of access a user has within AWARDS so that they can see and work with only that information for which they have the proper authorization. The System Setup module Permissions Maintenance feature is used to maintain user permissions, as well as to view read-only permission reports. It can also be used to configure the user groups to which permissions may be assigned.

Required Permissions

Unless you are a member of the "Executive Officer" and "System Administrator" user group, use of the Permissions Maintenance feature requires at least ONE of the following permissions:

Display Executive Administration Buttons

In addition, you must have ONE of the following permissions:

Permissions Data Entry (required in order to update or view permission records for yourself and your supervisees, if applicable)
Permissions Data Entry for All Staff and Layers (required to update or view permission records for anyone)

Members of the "Executive Officer" and "Human Resources" user groups, and users with the Human Resources Data permission are exempt from permission assignment limitations by default. They can update the permissions for all users without the Permissions for All Staff and Layers permission as long as they have the Permissions Data Entry permit.

In HMIS, multi-agency, or single-agency divisional databases the Permissions for All Staff and Layers permission is only available for assignment by "Continuum Staff." Users assigned to a specific agency within their staff information records in the Human Resources module will not have this permission available to them when using the System Setup module Permissions Maintenance feature.

Permissions are assigned using the Permissions Maintenance feature. If you do not have access to that feature and need a permission listed here, please contact your supervisor or your local Help Desk for assistance.

Understanding Permissions

All user access to the features and records within AWARDS is controlled by permissions (unless specifically noted otherwise). Those permissions are broken into a hierarchy composed of layers. Within each layer several distinct types of permissions can be assigned. This portion of the Resource Center is designed to help you understand both of these key aspects of permissions - layers and types - as well as to provide you with a guide to what each individual permission is designed to do.

Permissions Layers - Learn about the permissions hierarchy and its various layers.
Permission Types - Learn about each of the four permissions types and what they are used for.

Permission Descriptions - Learn about all available user permissions and how they can be used.

Configuring User Groups

The AWARDS database is set up with several default user groups to which permissions can be assigned on the User Group layer. The list of default groups can be added to and maintained using the Configure User Groups link within the System Setup module Permissions Maintenance feature.

In multi-agency, HMIS, and single-agency divisional databases, only "Continuum Staff" have the ability to configure and assign permissions to user groups. Users assigned to a specific agency within their staff information records in the Human Resources module will not see the Configure User Groups option under the System Setup module, Permissions Maintenance feature.

To create, update the permissions for, or delete a user group, complete the following steps from the AWARDS Home screen:

Click Administration from the left-hand menu, and then click System Setup. The System Setup fly-out menu is displayed.
Click Permissions Maintenance. The Permissions Selection page is displayed.
Click the Configure User Groups link. The Configure User Groups page is displayed. This page contains a list of all existing user groups, and the members of those groups.
At this time, complete one of the following user group configuration tasks:

Add a new user group and assign permissions to that group - To do so, in the Add New User Group field at the bottom of the page, type a name for the user group to be created. Continue with step 5.

Each user group name must be unique.

Update an existing user group's permissions - To do so, continue with step 6.
Delete an existing user group - To do so, click the Delete checkbox next to the user group to be deleted. Continue with step 5.

A user group can only be deleted if there are no users in it. To re-assign users to other user groups, use the System Setup module, Login Maintenance, Update User Group feature.

Click UPDATE USER GROUPS. Any new user groups are added to the list, and any user groups selected for deletion are removed. A User Groups Updated page is displayed. At this time, any of the following tasks can be completed:

Update the permissions for a new or existing user group - To do so, continue with step 6.
Update user group assignments - To do so, click the Update User Group Membership link at the bottom of the page to access the System Setup module, Login Maintenance, Update User Group feature.

Add another new user group or delete an existing user group - To do so, click Configure UserGroups and repeat steps 4 and 5 as needed.

If completion of none of these tasks is necessary, the process of configuring a user group is now complete. The steps that follow detail updating the permissions for a new or existing user group.

Click the name of the user group for which permissions are to be assigned. The Permissions for User Group Layer page is displayed.

No two users can update the permissions for the same user group at the same time. If another user is currently updating the permissions for the user group you have clicked, the Permissions for User Group Layer page cannot be displayed. Instead, a record "locked" notice is displayed, and you will be prompted to wait and try again later.

Click the checkbox next to each permission that members of the selected user group should be granted. To restore default (inherited) permissions for a user group rather than assign new ones, click the Restore Defaults button at the bottom of the page, and then click Update Permissions. (For more information on default permissions, see Permissions Layers. For more information on restoring defaults, see Re-Applying Inherited Permissions.)

Users can only assign program chart access permissions for those programs to which they themselves have access.

Permissions assigned to a user group will be overridden for specific group members if the individual layer for those members has been updated. If the individual layer has not been updated, the job title layer will be checked for permissions, and then the work role layer if the job title layer was not updated. If none of those layers were updated for a group member, he or she will be given access based on user group.

Click UPDATE PERMISSIONS. The permissions assignments are saved and a read-only report version of the updated user group permissions information is displayed on the Permissions for User Group Layer page.
At this time, any of the following tasks can be completed:

Make additional changes to the permissions of the user group you are working with - To do so, click the [Group Name] Data Entry link. The Permissions for User Group Layer page is displayed. Repeat steps 7 through 9 as needed.
Add another user group or adjust the permissions for other existing user groups - To do so, click Configure User Groups. The Configure User Groups page is displayed. Repeat steps 4 through 9 as needed.
Update user group assignments - To do so, click the Update User Group Membership link at the bottom of the page to access the System Setup module, Login Maintenance, Update User Group feature.

The process of configuring user groups is now complete.

Maintaining User Permissions

All permissions maintenance takes place within the System Setup module Permissions Maintenance feature, including the following common data entry tasks:

Updating Permissions - Follow this process to grant or deny specific permissions on a single layer for yourself or others, either individually or in a batch.
Removing Permissions - Follow this process to remove some or all permissions on a selected layer so that they can instead be inherited from another, higher, permissions layer.

IMPORTANT! When determining which of the above procedures you would like to review, please keep in mind that removing permissions is distinct from unchecking individual permissions - the latter of which happens during the updating permissions process. Unchecking a permission (followed by clicking update) denies access to the corresponding feature or functionality on the permissions layer on which it is unchecked. Conversely, removing permissions from a layer may or may not result in the user(s) being denied access to the corresponding features and functionality. Instead it will result in the user(s) inheriting the permissions from other, higher, permissions layers on which they may currently be granted (checked off) or denied (unchecked).

Updating Permissions

To update permission assignments for yourself or others, complete the following steps from the AWARDS Home screen:

Click Administration from the left-hand menu, and then click System Setup. The System Setup fly-out menu is displayed.
Click Permissions Maintenance. The Permissions Selection page is displayed.
Narrow record selection by configuring the options on this page:

Permissions Type - Click this drop-down arrow and select the type of permission for which permissions assignments are to be updated. Available selections are: "All Except Internal Audit Messages," "Internal Audit Messages," "Program Chart Access," "Data Entry/Access," "Exception Override," and "All Types."

An optional permission type - "Cross Chart Access" - may also be available in some databases. For more information on this permission type, please click here.

Permissions Layer - Click this drop-down arrow and select the layer of permissions for which permissions assignments are to be updated. Available selections are: "Individual," "User Group," "Work Role," "Job Title," and "Global."

In multi-agency, HMIS, and single-agency divisional databases, the "Global" selection is only available to continuum staff. Users assigned to a specific agency within their staff information records in the Human Resources module will not see the Global selection in the Layer drop-down list.

Changes made on any level other than the Individual layer apply only to new users whose permissions have not yet been updated, or to users for whom the default permissions have been restored for the Individual layer using the Restore Defaults option at the bottom of the Permissions page, but for whom those default permissions have not been updated. Exceptions to this are made in the case of some internal audit messages which can require specific work roles as well as individual layer permissions. For more information, see Understanding Permissions.

Division - Click this drop-down arrow and select the division for which permissions assignments are to be updated.

This option is only available in multi-agency, HMIS, and single-agency divisional databases. If you will be updating the permissions for continuum staff in those settings, set the Division selection to blank.

Database Mode - Click this drop-down arrow and select "Data Entry."

Click CONTINUE. The Selection for Permissions page is displayed.
The options on the Selection for Permissions page vary based on the selections made in step 3 above. Use the available options to further narrow which permissions are to be updated.

The specific permissions within each type included on this page, as well as descriptions of each, can be viewed by clicking the link to the left of the corresponding drop-down list.

When working on the individual layer, the list of users available for selection on the Selection for Permissions page is based on a combination of permissions and user group assignments. By default, users can only set permissions for themselves and their supervisees. Users who are in the "Executive" or "Human Resources" user groups, those who have the Human Resources Data permission, or those who have the Set Permissions for All Staff and Layers permission can set the permissions for all users.

Click CONTINUE. The Permissions for Layer page is displayed.

When working on this data entry page, please keep in mind:

Each permission's "source layer" is displayed in parentheses beneath it, indicating the layer of permissions from which it is being inherited, if any. If no inheritance is found (meaning that the permission has not been set on any layer), "Default Deny" will be displayed instead, reflecting that the permission is in its default state on all layers and is denied to the user.

No two users can update the permissions for the same user, group of users, or permissions layer at the same time. If another user is currently updating the permissions you chose to update on the Selection for Permissions page, the Permissions page cannot be displayed. Instead, a record "locked" notice is displayed, and you will be prompted to wait and try again later.
When working on the Individual layer and updating the permissions for a specific worker, the top of the Permissions for Layer page contains job title, user group, and work role information for that worker. When updating the permissions for all workers, this information is not displayed by default; however, it can be added to the page by clicking the View Job Title, User Group and Work Roles for All Workers link.

The permissions and assignees listed on the Permissions page vary based on the selections made in steps 3 and 5 above. For each permission listed, click the checkbox next to the person(s) or layer for whom that permission is to be granted.

When working on this data entry page, please keep in mind:

Users can only assign program chart access permissions for those programs to which they themselves have access.
Some permissions cannot be assigned to oneself; if a checkbox is bold, that permission must be granted by another user with access to Permissions Maintenance.

To remove assigned permissions for an individual or layer and to re-apply inherited permissions from higher layers rather than assign new ones, click one of the Remove Permissions buttons. For more information on inherited permissions, see Permission Layers. For more information on removing permissions, see Removing Permissions.)

Click UPDATE PERMISSIONS. The permissions assignments are saved and a read-only report version of the updated permissions information is displayed on the Permissions for Layer page.

When working on the Individual layer, an informational pop-up message is displayed after clicking UPDATE PERMISSIONS. As explained in that pop-up, permissions changes made for a user while that user is currently logged into AWARDS will not take affect until that user has logged out of AWARDS and logged back in again. Click OK to acknowledge the pop-up and view the Permissions for Layer page.

To make additional permissions changes, click Data Entry. The Permissions for Layer page is displayed. Repeat steps 7 through 9 as needed.

The process of updating permissions is now complete.

Removing Permissions (Re-Applying Inherited Permissions)

Unless and until permissions are set for a given user on the Individual layer of permissions, his/her system access is set based on any permissions "inherited" from the other, higher, permissions layers (such as User Group, Work Role, Job Title, and Global). In some instances it may be necessary to re-apply the inherited permissions for an individual user or permissions layer using the Permissions Maintenance feature's Remove Permissions functionality. For example, removing permissions from the Individual layer could be used in the following scenarios.

The permissions for a user group are changed, and those changes should be applied to a member of the user group for whom Individual layer permissions exist.
A new user group is created, a user for whom Individual layer permissions exist is assigned to that group, and the User Group layer permissions should be applied to him or her.
A staff person's user group is changed and you now want them to inherit the permissions from their new user group.

In each of these examples, removing permissions and re-applying inherited permissions sets for the user all permissions applicable to him or her from those layers above the Individual layer (User Group, Work Role, Job Title, and so on). Without restoring defaults in these cases, permissions from the User Group layer would not affect the members of that user group when Individual layer permissions exist for those members.

Please keep in mind that removing permissions is distinct from unchecking individual permissions - the latter of which happens during the updating permissions process. Unchecking a permission (followed by clicking Update) denies access to the corresponding feature or functionality on the permissions layer on which it is unchecked. Conversely, removing permissions from a layer may or may not result in the user(s) being denied access to the corresponding features and functionality. Instead it will result in the user(s) inheriting the permissions from other, higher, permissions layers on which they may currently be granted (checked off) or denied (unchecked).

The re-application of inherited permissions can be performed on any permissions layer, and for any combination of permission types. It only deletes the existing permissions on the layer for which it is used, and for the permissions type specified. For example, removing some or all permissions on the User Group layer only removes those existing permissions for the selected user group and applies to that user group the inherited permissions from those layers above it. It does not impact the Individual layer permissions of any users in that user group.

When permissions are removed on the Individual layer and inherited permissions are re-applied, any permissions specifically assigned to the individual by Foothold Technology will need to be re-requested. This includes permission for Program History Corrections, Merge Consumers, E-Prescribing, and other pieces of limited-access functionality. Please contact the Help Desk for assistance in such cases.

To remove existing permissions on a specific layer and to re-apply inherited permissions from a higher layer, please complete the following steps:

From the AWARDS Home screen, click Administration from the left-hand menu, and then click System Setup. The System Setup fly-out menu is displayed.
Click Permissions Maintenance. The Permissions Selection page is displayed.
Click the Permission Type drop-down arrow and select the type of permission to be worked with. Available selections are: "All Except Internal Audit Messages," "Internal Audit Messages," "Program Chart Access," "Data Entry/Access," " Exception Overrides," and "All Types."
Click the Permission Layer drop-down arrow and select the layer to be worked with. Available selections are: "Individual," "User Group," "Work Role," "Job Title," and "Global."

Click the Division drop-down arrow and select the division to be worked with.

This option is only available in multi-agency, HMIS, and single-agency divisional databases. If Division is set to the blank selection, any permissions changes are applied to all divisions/agencies in the database. For example, to make global changes to a specific user group, select "User Group" for the permissions layer, and set the division to blank. One exception to this rule is found on the Individual layer where a blank division selection allows for the updating of permissions for continuum staff only.

Click the Database Mode drop-down arrow and select "Data Entry."
Click CONTINUE. The Selection for Permissions page is displayed.
The options on the Selection for Permissions page vary based on the selections made in step 3 through 5. Use the available option at the top of the page to narrow which group or individual within the selected permissions layer is to have the defaults restored. Leave all permission selection options set to the default "All" selections.

When working on the individual layer, the list of users available for selection on the Selection for Permissions page is based on a combination of permissions and user group assignments. By default, users can only set permissions for themselves and their supervisees. Users who are in the "Executive" or "Human Resources" user groups, those who have the Human Resources Data permission, or those who have the Set Permissions for All Staff and Layers permission can set the permissions for all users.

Click CONTINUE. The Permissions for Layer page is displayed.

When working on this data entry page, please keep in mind:

Each permission's "source layer" is displayed in parentheses beneath it, indicating the layer of permissions from which it is being inherited, if any. If no inheritance is found (meaning that the permission has not been set on any layer), "Default Deny" will be displayed instead, reflecting that the permission is in its default state on all layers and is denied to the user.

No two users can update the permissions for the same user, group of users, or permissions layer at the same time. If another user is currently updating the permissions you chose to update on the Selection for Permissions page, the Permissions page cannot be displayed. Instead, a record "locked" notice is displayed, and you will be prompted to wait and try again later.

When working on the Individual layer and updating the permissions for a specific worker, the top of the Permissions for Layer page contains job title, user group, and work role information for that worker. When updating the permissions for all workers, this information is not displayed by default; however, it can be added to the page by clicking the View Job Title, User Group and Work Roles for All Workers link.

Click one of the available remove permissions buttons:

Which of these buttons you see is based on the selections made in the previous steps. Not all remove options are available in all instances.

Remove All _____ Permissions on This Layer - Each section (type) of permissions on the data entry page has a Remove button beneath it that, when clicked, removes all permissions of that type on the specific layer you are working with, and re-applies all inherited permissions from other higher permission layers, when applicable.
Remove All Permissions Except Chart Access on This Layer - When this option is used, all permissions on the layer you are working with are removed, EXCEPT for the program chart access permissions. Whatever chart access permissions are in place prior to the removal continue to be in place afterward, and only internal audit message, data/entry access, and exception override permissions from the layers above the layer you are working with are re-applied.

This option is only available when the Permission Type was set to "All Types" in step 3.

Remove All Permissions On This Layer - When this option is used, all permissions on the layer you are working with are removed, INCLUDING program chart access permissions. Any inherited permissions from higher layers are re-applied in their place.

This option is only available when the Permission Type was set to "All Types" in step 3.

Click OK. The updated Permissions for Layer page is displayed, including on-screen information confirming completion of the removal, and providing instructions advising you of your next possible steps and their results.
At this time you have two options regarding how to proceed:

Exit data entry to save the re-applied inherited permissions and to ensure that future changes to higher permissions layers are applied - To leave the newly re-applied inherited permissions in place AND to make sure that any future changes to higher permissions layers are automatically applied to this permission, type, layer, or individual user, do NOT make any other changes on this data entry page, and do NOT click Update. Instead, click Home to exit the data entry process.
Make additional changes as needed by checking or unchecking individual permissions - When complete, click Update Permissions to apply your changes. Keep in mind that if you choose to proceed in this way any changes made on higher permissions layers in the future will NOT be applied to the permission, type, layer, or individual user you are currently working with.

The process of removing permissions is now complete.

Frequently Asked Questions

Are there any permissions that only Foothold staff can assign to users?

Yes, there are several pieces of subscription-based functionality in AWARDS for which permissions can only be granted by Foothold Technology. These permissions, noted with the instructions on related functionality throughout this document, can be requested by contacting the Help Desk or by following the instructions provided with the permission information, such as completion of a related Service Agreement. Included among these permissions limited to assignment by Foothold Technology are those for E-Labs, E-Prescribing, and Interoperability Center access.

Can a user have more than one work role?

Yes. For more information on work roles as they relate to permissions, see Permissions Layers.

Can a user receive internal audit messages without having chart access?

No. A user needs chart access permission, set on the individual permissions layer, for all programs for which he or she should receive the internal audit messages; however, be assured that giving the user those permissions will not give him or her access to client records as long as he or she does not have the "Display Any Chart Records Buttons" permission.

Can chart access be limited to demographic information only?

Program chart access cannot be limited. If a user has access to the charts in a program, that user will be able to see information in all modules he/she has access to.

Can I give a user permission for data entry in one program and read-only access in another?

Currently there is no way to apply read-only restrictions to some programs and not others. It is only possible to make the user's access read-only for all programs to which they have access or to allow them data entry access to all of those programs.

Does anyone have chart access permission to a program by default?

Yes. When a new program is created the following individuals are automatically granted chart access permission to it:

Members of the "Executive Officer" user group (in a single-agency database) and "CoC Executive Officer" user group (in a multi-agency database)
Members of the "Agency Executive Officer" user group (in a multi-agency database) if the new program was created within their agency
Members of the "Local CoC Admin" user group (in a multi-agency database) if the new program was created within their jurisdiction (for example, their county or CoC within the larger multi-agency database/continuum)
Members of the "System Administrator" user group

The individual who created the program in AWARDS

Additionally, when a program director and/or deputy director are later assigned using the Configure Administration feature, they are given default chart access. Individuals with caseloads in the program are also given access once those caseloads have been set up.

If any of these individuals do not require chart access to the new program, it can be removed using the System Setup module's Permission Maintenance feature.

Is a user considered a "primary service coordinator" if all clients on his/her caseload have been discharged?

No. In the event that a service coordinator's clients have all been discharged, he or she is no longer considered a "Primary Service Coordinator" for work role purposes.

Is there a way to limit workers to only a subset of clients in a program to which they have chart access?

Yes, the optional Restricted Census Access feature enables agencies to limit workers and grant them access to only specific clients in a program for which they have chart access. For more information, click here.

What are "Cross Chart Access" permissions?

By default the Client History Report accessed from within Client Search can be viewed for clients in at least one program to which the user has chart access. The content of the report itself is also limited by chart access; the user will only see records for the programs to which he/she has access, even when a client is in other programs as well. An optional enhancement is available which adds a new cross chart access permission that, when assigned, expands the content of the Client History Report to include the full complement of a client's program records, regardless of chart access permissions. There are "global" and "specific" versions of the new permission, of which ONE can be selected for deployment to your database.

IMPORTANT! This enhancement impacts only the content of the Client History Report. It does not change who can access the report (users with chart access to at least one of the client's programs), nor does it impact user access to client records outside of the Client History Report.

Global - When using the "global" version of this enhancement, a new "View All Charts of Client if Can View Any" permission is added to the System Setup module Permissions Maintenance feature. When this data entry/access permission is assigned to a user and he/she runs the Client History Report, the report includes the records for each of the selected client's programs, even those to which the user does not have chart access.

An exception to global cross chart access is found with programs identified as protected under System Setup > Agency Program Information > Add/Edit Entire Program . Data from those programs will not be included in the Client History Report unless the user has the actual chart access permission for them.

Specific - When using the "specific" version of this enhancement, a new "Cross Chart Access" selection is added to the Permission Type selection list in the System Setup module Permissions Maintenance feature.

When the Cross Chart Access permission type is selected and the permissions data entry process is continued, you are given the opportunity to select a user and a program to which he/she has chart access permission. Upon continuing you are then given the option of granting cross chart access to that user for specific program clients for the other program(s) of those clients. When the Client History Report is then run for one of those clients, it will include his/her records for both the programs to which the user has chart access permission, and for those other programs to which the user has cross chart access.

An exception to specific cross chart access is found with programs identified as protected under System Setup > Agency Program Information > Add/Edit Entire Program. Data from those programs will not be included in the Client History Report unless the user has the actual chart access permission for them.

If you are interesting in having one of the Cross Chart Access permission versions described here deployed for your AWARDS database, please contact the Help Desk.

What does the error "you need a permit for permits" mean?

In order to use the System Setup module Permissions Maintenance feature, you must have either the "Permissions Data Entry" or the "Permissions Data Entry for All Staff and Layers" exception override permission. The "You need a permit for permits" error message is designed to let you know that you do not have the required permission, and that as a result you will need to contact your agency/continuum's System Administrator or your supervisor. He/she will either assign you the necessary permission, or make the permission changes you wanted to make for yourself/your staff based on your agency/continuum's protocols.

What does the "Read-Only option for each of the "Display Chart Records" data entry/access permissions do?

If a user has been granted permission for a specific AWARDS chart records module (or Home screen button) using the corresponding "Display Chart Records" data entry/access permission, a Read-Only checkbox is also made available for that permission. It appears on all permission assignment layers and follows the existing rules of permission inheritance between layers.

When the Read-Only option is checked off for a module, the user will have access to the module, but be restricted to read-only viewing. Users with read-only access to a module can view the module's information in various places in AWARDS, but cannot access it in data entry mode. Users are prevented from accessing data entry for these modules via the face sheet, Consumer Search menu, dynamic sections within FormBuilder forms, and the Calendar.

Example 1: If a user is assigned read-only access to the Medical module, he will still be able to view medical sections of the face sheet, but the corresponding "Update" buttons will not display. He will be able to view medical data on FormBuilder forms, but not access them in data entry mode. He will be able to view scheduled medical appointments on the Calendar, but will not be able to schedule one.
Example 2: If a user needs access to enter Services documentation, but does not need data entry access to any other module, she can be given access to the Services modules, and read-only access to all other modules. This would allow her to view and print face sheets, intake forms, medication sheets, etc., if needed, while protecting the data recorded in those locations.

One exception to how the Read-Only option works can be found with the Medical module Contacts feature. As is standard, users with read-only access to the Medical module cannot enter data in the Contacts feature within that module; however, unlike with other Medical features whose data is accessible via the face sheet, users CAN enter contacts information from within client face sheets. Similarly, users with this level of permission can also enter contacts from the calendar when Consent End Dates is selected under "Included Events" while in the Consumer or Program view.

When does the "Startup Period Backdating" permission expire exactly?

That permission expires thirty days from its assignment. Specifically, if I assign the permission today, it will expire as of midnight thirty days from today. It would be in place all day that final day, regardless of what time the permission was assigned today.

When setting Internal Audit Message permissions on the Work Role layer for "Direct Care Supervisor", does the supervisor of a client's Primary Worker receive the messages?

All Direct Care Supervisors who have program chart access to the programs in which the client is enrolled will receive the internal audit messages set on the Work Role layer. The supervisor in question does not have to supervise the Primary Worker of the client for whom the messages are generated; instead, he/she only needs to supervise any worker in the program associated with the message, or supervise any worker in any program in which the client is enrolled.

When setting permissions, why would I choose the "All Except Internal Audit Messages" permission type instead of "All Types?"

Typically internal audit message permissions are set on the User Group and Work Role permissions layers. If you were to select "All Types" when setting permissions on a layer besides those (for example, in the Individual layer), you might inadvertently impact a user's inheritance of internal audit messages from those two higher layers. By selecting "All Except Internal Audit Messages" as the permission type instead, you have the freedom to adjust a user's permissions without worrying about the interplay between permission layers that most often impact the internal audit messages.

IMPORTANT! Other permissions besides those for internal audit messages may also be set at layers other than the Individual layer. As a result, it's important to be aware of how your agency has chosen to grant/deny permissions in a general sense before making any changes. This permission type option is simply meant to help you avoid the scenario most frequently found to be problematic for staff working with Permissions Maintenance.

Where do I check off work roles for a new employee?

Work roles are not user-defined, they are automatically determined by AWARDS based on things like caseloads, supervisor assignments, and more. For detailed information on the definition of each work role, click here.

Who can create user groups in multi-agency/HMIS databases?

In multi-agency and HMIS databases the ability to create user groups is limited to those users who are set up as "continuum staff," meaning they have access to all agencies within the database. Whether a user is "continuum staff" or associated with a specific agency is determined by his or her staff information record in the Human Resources module.

Who can I update permissions for?

By default, users with the "Permissions Data Entry" permission can use the System Setup module Permissions Maintenance feature to set permissions only for themselves and their supervisees, if applicable. Users with the "Permissions Data Entry for All Staff and Layers" permission are exempt from the default and can set the permissions for any users.

Members of the "Executive Officer" and "Human Resources" user groups, and users with the Human Resources Data permission are exempt from permission assignment limitations by default and do not need the Permissions for All Staff and Layers permission as long as they have the Permissions Data Entry permit.

In HMIS, multi-agency, or single-agency divisional databases the Permissions for All Staff and Layers permission is only available for assignment by "Continuum Staff." Users assigned to a specific agency within their staff information records in the Human Resources module will not have this permission available to them when using the System Setup module Permissions Maintenance feature.

Who receives notification messages when permissions are changed?

System generated messages for permissions changes are sent to users who have the "Permission Change Notification" permission assigned to them.

Why am I receiving "Program Appointment Reminder" internal audit messages? I don't see a permission for them.

Program Appointment Reminders are automatically sent to users who have the Medical Appointment Reminders permission if they have chart access to the program for which the reminders are being generated and they also meeting the work role permissions layer rules for the Medical Appointment Reminders permission. These Program Appointment Reminders cannot be turned on by themselves, and cannot be turned off if a user has the Medical Appointment Reminders permit.

Program Appointment Reminders are set three days before the appointment date and then every day after the appointment date has passed, until the appointment status has been updated (with the exception of Saturdays and Sundays).

Why are some permissions checkboxes bold on the data entry page?

Some permissions cannot be assigned to oneself; a bold checkbox is an indication that the permission must be granted to you by another user with access to Permissions Maintenance.

Why are some users not receiving internal audit messages or receiving the wrong ones?

When there is a problem with the internal audit message distribution list, begin troubleshooting by examining the Individual and Work Role permissions layers for the user in question. How the internal audit message permissions are set on those two layers will determine who audit messages are sent to. If the permissions appear to be set correctly but there is still a problem with the distribution lists, please contact the Help Desk for assistance. Be sure to provide them with the name of the user who did not receive the message, the type of message you expected him or her to receive, and an example of a recent message of that type that they were not included on.

Why aren't a user's permissions different after he/she was placed in a new user group?

If you would like the user to have the default permissions set up for his or her new user group, you must open the user's Individual layer of permissions and click one of the available Remove Permissions buttons. Using one of these options removes all existing permissions for the user and gives to him or her those permissions from the layers above. For more information on restoring permissions for the purposes of re-applying inherited permissions, see Removing Permissions.

Why aren't chart record modules assigned to a user included on his/her Home screen?

In addition to giving the user permission for the specific chart records modules you want him or her to have access to, you must also give that user the general "Display Any Chart Records Buttons" permission. Without that permission chart records modules are prevented from showing up on the user's Home screen.

Why aren't users who have the correct permission receiving note lapse internal audit messages?

The note lapse feature must be activated before the permission will take effect. If you would like to use this feature, please contact the Help Desk.

Why can I update permissions for all staff when I only have the basic "Permissions Data Entry" permission?

Members of the "Executive Officer" and "Human Resources" user groups, and users with the "Human Resources Data Full Access" permission are exempt from permission assignment limitations by default and do not need "Permissions Data Entry for All Staff and Layers" permission as long as they have the "Permissions Data Entry" permit.

Why can't I assign myself a "Human Resources Data" permission?

Because the "human Resources Data" permissions are powerful and directly impact a user's ability to view and work with staff information data, they cannot be assigned to oneself; instead, they must be assigned by another user. For more information on what each of the three Human Resources data permissions gives a user access to, please click here.

Why do some permission changes not generate an internal audit message?

Use of the System Setup > Permissions Maintenance > Remove This Permission on This Layer option is excluded from the permission changes that generate an internal audit message to users with the Permission Change Notification permission.

Why does a user with chart access to only one program have an "all agency programs" option in his/her program selection list?

Users only have permission to see data for clients in the program(s) to which they have explicitly been granted chart access. Any "all" program selections place the same restrictions on users; for example, when running a report for "All Agency Programs," a user only sees data for the program(s) to which he/she has chart access, not to all programs in the agency/continuum.

Why does the notification message I received after updating permissions indicate I changed a permission I did not touch?

Occasionally, upon updating permissions on the individual layer you will receive a permission change notification that indicates you updated a permission you did not in fact change. Some of the permissions that display on the individual layer are inherited from different layers (work role, job title, etc.), but as a matter of fact they have not been granted on the individual layer. The first time an individual's permissions are updated on the individual layer, these permissions are saved to this layer, and are therefore included in the update notification message.

Why don't I receive 30 day note lapse notification messages for "pending" clients? I have the note lapse permission.

The 30 day note lapse notification applies only to those clients who have an admission date in AWARDS. Pending clients - those for whom intake has been processed but not admission - do not have an admission date and as a result will not generate note lapse messages.

Why don't I see all available permissions under Permissions Maintenance?

Not all permissions referenced in the Resource Center will be viewable/assignable by all users with access to Permissions Maintenance. This can be the result of database setup, or individual levels of access. For example, you cannot assign chart access permission to a program for which you do not have the permission assigned to yourself. Also, some permissions are not available in multi-agency/divisional databases (for example, Merge Duplicate Sources). In some cases functionality made accessible by permissions that are not available in your AWARDS database can be turned on behind-the-scenes for individual users. More detail on those permissions can be found under Permission Descriptions.

Why don't I see every program listed in the Program Chart Access section of the permissions page?

You can only see and assign chart access to those programs to which you yourself have access. If a program exists for which you were never granted chart access, it is not displayed on the permissions page.

Why isn't a user noticing a difference after I update his/her permissions?

In the event that you change a user's permissions while he or she is currently logged into AWARDS, he or she must return to the AWARDS Home screen in order for those changes to take effect.

Why weren't all permissions changes I made captured in the permission change system generated message?

System generated permission change notifications are only sent when permissions are added or removed for specific users on the individual permissions layer. Note that checking off a "No Role Required" option on the individual layer is considered a modification rather than an addition, and such action is therefore not included in the notifications.

Why would I get a notification message when updating one user's permissions but not another's?

Notification messages are only sent when changing permissions on the Individual layer. If you made changes to the permissions of many users at once by using the "All Workers" option, or if you were making changes at a layer other than Individual, you would not receive a notification message.

Related Reports

Other Helpful Resources

Webinar Recordings

Permissions Setup & Administration - iKnow AWARDS (1 hr 10 min)

Designed for users at agencies currently in the AWARDS implementation process who will be setting and managing permissions in their AWARDS database, this recording reviews the process of setting permissions, from creating permissions policies to limit access to programs and data entry features, to managing internal audit messages so that staff can receive reminder messages about clients on their caseloads. (March 2018)

Permissions 202 - User's Conference Continued (1 hr 1 min)

Learn how to create a framework for your permissions based on your user groups in order to create consistency around your different groups of AWARDS users. Learn how to change and re-set permissions as needed. Participants will also learn how to limit which users receive internal audit messages so they only receive messages that are applicable. Attendees will leave this session feeling confident in changing permissions without fear of unintentionally upsetting users access. (June 2018)