The following frequently asked questions provide details on the most commonly asked about pieces of the Permissions Maintenance feature. Click a question from the list here to navigate directly to the corresponding answer, or scroll through the full list of questions and answers below.
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.
Yes. For more information on work roles as they relate to permissions, see Permissions Layers.
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.
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.
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.
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.
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.
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.
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.
NOTE: 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.
NOTE: 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.
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.
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.
NOTE: 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.
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.
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.
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.
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 and navigate to the work roles portion of the page.
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.
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.
NOTE: 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.
TIP: 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.
System generated messages for permissions changes are sent to users who have the "Permission Change Notification" permission assigned to 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.
NOTE: 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Not all permissions referenced in Online Help 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.
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.
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.
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.
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.