User Management gives you operational control of who is allowed to login and use your business operations solution. You can define 1 of 2 user types when adding new users;
- A normal ‘User’
- A Self-Service ‘User’
A normal user is typically an employee. The employee is a fixture of your business and will have rights assigned to them, by you, to access those areas of the solution that relate directly to their employ.
A self-service user is an external user who requires a login to do things on your solution, but is typically not an employee. They could be a customer! They could be a partner! They could be a contractor; who needs a login, for example, to submit timesheets to you based on the work they are doing for you on one of your Projects.
Full Users typically have a deeper and more established need to access the solution. A self-service user has a shallower set of permissions to fewer application elements.
Each application package you buy has a set number of ‘Users’ included; or could be a set of ‘self-service’ user logins enabled. With each package you buy you can extend the number of ‘users’ allowed to access each package. In User Management you begin the task of assigning the applications and entitlements to your ‘Users’.
You can also see each Users Role, login details, their approval status, when they registered, their online status, their last logged in date, their permission group, their locked out status or the blocked status. You have complete environmental control over all of these facets as the main administrator.
For each user on your solution you can EDIT their details or RESET their password using the dropdown next to the PENCIL icon in user list view. You can also delete a user using the Trash Can. You can also block them or lock them out of being able to log in if so desired.
Editing a User
Editing a User – Example
Fields with a RED Background are mandatory. Fields with a white background are optional. Users once logged in are able to change many of these details; but not all. in some cases you as the main admin as responsible. In most cases the fields are self-explanatory;
Photo – upload or add a picture of the User as this personalises their experience throughout the solution
First Name – the Christian Name (Full, as given at birth for this user)
Middle Name – the middle name of this user if they have one; very handy if you have two x John Smith working in the Company!
Last Name – the full given Family name (surname)
Gender – Male/Female
Salutation – Mr, Miss, Mrs, Doctor, Professor etc
Preferred Name – Dave versus David, Bill versus William etc
Maiden Name – Surname prior to Marriage causing a change of family name
Primary Email – this cannot be changed and is fixed throughout the solution. It can only be changed by submitting a support ticket
Phone – preferred main telephone number
Mobile – preferred main mobile telephone number
Marital Status – Married, Divorced, Single etc
Ethnic Group – should your company wish to retain these record types
Preferred Language – free text to describe their preferred language
Religion – use if your company records this information for reporting purposes
Citizenship – use if your company records this information
Birth Date – Date of Birth
Status – employment status
Permission Group – the group that this user belongs to. It sets their permissions and privileges. (See Permission Group area of the documentation for details)
Job Title – their job title as it would be written on a business card
Location – from your Office Locations from Company Set Up
Time Zone – their normal working time zone so that calendars reflect their local time
Administrator – tick this to make them a main admin across the solution
Purchase Administrator – tick this to enable this user to manipulate package subscriptions and payment information/records/history
Note; this should be considered a basic ‘human resources’ management capability seen as a whole. By adding the ‘Human Resources Management’ application package/suite you may significantly increase the range of information and data collected about each employee/user on your system.
You will not see any application management credentials until such a time as your company is actually suscribed to an active application. For each package you own you will have a set number of users enabled in that entitlement; either by default or by adding users. These elements only appear if you have an active subscription; they are missing in free-trials or other pre-subscription package types.
Where a subscription is ACTIVE you will see a PACKAGES tab on the left of the User Edit form. Use this to enable access to a package/application for this user;
Managing a Users access to activated packages on your subscription
Simply tick the boxes to assign rights to this application/package for this user and then press the button marked OK to save it.
Packages are administered separately to Users. Users roles and privileges are managed separately too. Finally the visibility of entitlements that any user has is a function of the permission group to which they belong; so in theory; you could add eHuman Resources to a User as a package entitlement; only to find that you have not activated eHR in their Permission Group! You will need to work your way carefully through the process of firstly;
Firstly, buy the package/s in question. Define your user permission groups for that application package or make changes to existing permission groups so that the application can ‘show’ itself where relevant. Then add your users to the solution if they aren’t users already, then add those users to that permission group. Get any one of these stages wrong and you’ll quickly notice! Don’t let it daunt you; it is not challenging; just think about the natural process you would follow in a non-software scenario of the same type.
Before adding users we recommend that you set up your ‘Permission Groups’ first as the process of adding a user of either ‘type’ requires you to select the permission group to which they will be assigned. You could set up a basic standard permission group which has zero entitlements to any privileges and use this as the default group when adding users; going on to change their permission group and permissions after they have received company training, for example. You may define as many permission groups as you need; you could even have one for each employee. More typical, though, is to have permission groups which are relevant departmentally or based on typical ‘roles’ throughout your company. If necessary you can copy an existing permission group and tweak it slightly if a subtle change is needed for a handful of employees. You should strive to find a balance between too many permissions groups; making things difficult to manage; versus too few; where you risk providing employees with access to something that they don’t fundamentally need.