How do I create and assign Account Roles

This article will explain how to create an assign Account Roles to staff members.

Account Roles / Security Roles and Privileges

Contents:

* Identifying your needed Account Roles
* Assigning users to the Account Role
* Adding some default values to the Account Role
* Adding Notes
* Adding Files
* Some additional Comments

Account Roles and Privileges control the access of data. They protect sensitive data and enable collaboration. They identify what a user can see and access. To control what a Staff Member can access, the System Administrator can create, edit, or delete the privileges of that user.

Each Staff Member can have one or more roles assigned to them. In imPowr, Account Roles are located under Settings and Security menu item in the System Module.

An Account Role can be created, edited, copied, or deleted. In imPowr, Account Roles consist of controls are the system level, page level, field level, program level, as well as at the portal level.

ACCOUNT PRIVILEGE

DESCRIPTION OF HOW USED

Functional Rights

Used to control the pages, page sections, and buttons available to users. There is some overlap/interaction with Entity Rights.

Dashboard Rights

Used to control access to dashboard docks and workflows (the shortcut buttons that appear on the left of the dashboard).

Entity Rights

Used to control a user’s ability to add, edit, view, and delete various objects. There is some overlap/interaction with Functional Rights. So, without these rights, even though you might be able to see a page, you may not be able to do anything with it unless you have the proper Entity Rights.

Program Rights

Used to restrict client details to only staff involved with a particular program.

Portal Rights

Used to control what panels appear on the various types of portals.

Entity Details

Used to control access depending on attributes within an entity.

The goal for assigning Account Roles is to only establish a single role for each person, and to create as few goals as possible for the organizations. This does not always work, but it is something to strive for. The way to do that is to completely understand what activities each staff member’s role is, and what screens they need to have access to. For some organizations, providing full access (except to confidential areas or areas of configuration or password changes) is acceptable, because if something were to occur, the activities are mostly captured in the Audit Trail. For others, tighter restrictions are required.

Identifying your needed Account Roles

The overall process for coming up with the proper Account Role is as follows:

1. Identify roles in your organization.
2. List the main things they need to do (manage accounts, manage equipment, log in, etc.).
3. Build basic groups for those roles taking the approach of “too little” rather than “too much” since it’s easier to add things in later than remove them.
4. Fine tune the roles as required.
5. Test them out as a System Admin by selecting those roles and viewing what they can and cannot do.
6. Assign people to the Account Roles and Launch.
7. Make any necessary changes and add in things to Account Roles as they come up.

The organization, the roles of its staff, and the individual staff members all come into play when creating and assigning Account Roles. Your Continual Care Solutions Project Manager can guide you through that process if you need help.

Note: The Account Role for all users who get imPowr access requires the Application Login functional right, as well as the Page – My Dashboard functional right so they can have access to selected menu items. Users who only require portal access, only need that portal right set up for their Account Role.

Assigning users to the Account Role, in the Member tab

When Staff Members are assigned to the Account Role, they appear in the Member tab. They can also be added to this tab directly…

• Click on the ‘+’.
• **Choose **(an) Account by clicking in the checkbox to the left of the Account Name and clicking on Save.
• Save your changes by clicking on Apply or Save.

Note: Both Apply and Save save your screen. When you click on Apply, you remain on the same page after saving. When you click on Save, you are exited from the current screen after saving.

Adding some Account Role default values, in the Settings tab

The Settings tab controls some default values and views of the intake
prescreen questions, which are not controlled from within the configuration pages. In this tab, you can set the default business type, client type, service list preferences, identify if you require all clients to have a program, and whether you want to show the prescreen questions in the intake form for new family and individual clients.

To change settings…

• Click on the Setting ID.
• Enter or change the entry Value.
• Save your changes.
• **Apply **the changes to your Account Role.

Adding notes in the Notes tab

Add any notes to the Account Role by…

• Click on the ‘+’.
• Select the note Privacy Level and Effective Date.
• Enter (the) Note.
• Save the note.
• Click on **Apply **to save the addition of your note(s) to your Account Role.

Delete any notes by clicking on the checkbox to the left of the note and clicking on the ‘-‘ button.

Adding files in the Files tab

Add any files to the Account Role by…

• Click on the ‘+’.
• Select a File to Upload.
• **Upload **the file.
• Click **Apply **to save the addition of the file(s) to your Account Role.

Delete any files by clicking on the checkbox to the left of the file and clicking on the ‘-‘ button.

Save the Account Role when you are completed with all additions, changes, and deletions.

• Click on** Save**.

Additional Comments about Account Roles

While Account Roles may seem daunting, they are not as complicated as one might think.

The main things to remember are:

• Roles are not exclusive (i.e. just because one role can do something doesn’t stop another role from doing it too)
• A person only uses one role at a time. In some systems the roles “add together, but Continual Care does it like Microsoft does in that each role is independent so even though a user may have access to many different roles, the user is only in one role at a time. That why for most users – is it recommended that they be put in one role only.

When setting up a role for a person – System Admins can just create one role that does all the “stuff” that a person in that role needs to do, and give them that role. So for example, for an IT Support person in an organization who needs to do a COVID-19 Wellness check each day, resets user passwords, keeps track of PCs, occasionally runs some staff list reports to bounce against other lists, they probably need:

• Wellness access.
• Access to the staff account list and the ability to edit the accounts (needed to reset passwords).
• Eventually we want them using the equipment and technology lists for tracking inventory, so we should give them that.
• For troubleshooting user issues, we may want them to have access to the audit trail and some of the system admin tools.
• And finally, perhaps they should be given access to some staff reports too and maybe a dashboard.

For them, a single role called “IT Person” can be created that does wellness and equipment, etc.. And, once the IT person is assigned to that role, they can do all of the above.

The advantages of using Account Roles is Administrators never have to “take away” a privilege to give a different one. System Administrators can create the roles needed so that any user can do whatever they need to do – that’s why
there are unlimited roles and unlimited combinations of roles. Just think through what that person needs to do – pick the privileges – and the user is ready to go. In the extreme case, one entirely unique role for each person can be defined. Of course, that becomes cumbersome to maintain. So some business practices to make it more manageable are needed.

It’s the same challenge a business has with pay scales and benefits too. If an organization had to come up with a custom strategy for each person it becomes a burden to manage. So to deal with that, businesses use job classifications. For example, in many companies, there are multiple levels of people with the same job title. Having job classifications is the way to compromise between a separate strategy for each individual person and one-size-fits-all on the other extreme.

So, the best way to handle these is to think through the classifications, create a list and assign privileges. For example, if what the Supervisor does is different than what the staff person does, then make them separate. If they are the same keep them as one role. And if they are mostly the same except for one or two things, make a judgment call as to whether or not a single role can be used for both. Is it worth defining and maintaining another role – or should users just be assigned the same privilege and one person may or may not use it?

In the above example, let’s say only some people were designated to do a certain job but only one role was created for the organization. Is it really so bad if all the users have the designated privilege? What’s the downside? Possibly the worst might be they do something when they are not supposed to. Chances are they never would – but even if they did, what’s the downside? And If they do – there is evidence of that in the audit trail and they can be terminated or other due to their actions, if it is deemed appropriate.

Ultimately, the System Administrator must decide how specific they want to get with a role – to the extreme of everyone getting their own role – but based on our experience, most organizations have been able to pare it down to 5 - 10 Account Roles in total, that cover everyone.