User Properties help Staff complete tasks where information that is specific to that member of staff is needed. This type of Information can be pre-populated in the Client App to save re-keying.
What is this article about?
This article continues the theme of setting up your Data Dictionary in the App Designer. The principle of minimising data entry and eliminating re-keying is an important part of publishing configuration to the Client App that is easy to use for frontline workers. We will look specifically at setting up User Properties, which can be used to pre-populate fields specific to the frontline worker.
What you will need.
You will need...
- App Designer installed on your PC
- Your account 'on boarded' in the platform (check with your system administrators)
- At least the 'Designers' role. If you are going to deploy configuration, then you will also need the 'Publishers' role.
User Properties - Principles
- There are two types of User Property:
- Obtained from the User's corporate login account e.g. Azure AD or Google Account, or
- Obtained from the User's account in the PoliceBox/Quvo platform via the Web Portal
- User Properties from either type can be used simultaneously so that a comprehensive set of pre-populating fields can be established for use on any Task design.
- User Properties that are obtained from the corporate login account are pre-determined by the platform, you simply need to create the necessary entries in the Data Dictionary.
- User Properties that are obtained from the PoliceBox/Quvo can be completely controlled by your organisation. The values for these User Properties can be set by the User themselves using the Self-service part of the Web Portal.
This short video shows the manner in which User Properties are harnessed in the platform for either type of User Property.
We will explain how to manage either type of User Property in the remainder of this article.
User Properties - Corporate Login Account
User Properties which are obtained from the corporate login account are pre-determined by the platform and take into account the most common fields available in LDAP compliant systems such as Azure AD.
This image shows how properties from a user's corporate account can be mapped to individual entries in the Data Dictionary. While the fields are pre-determined in the platform, to use them, you must create the relevant entries in the Data Dictionary.
The table provides a list of the pre-determined set of User Properties that can be added to your Data Dictionary for a corporate login account.
The name of the Data Dictionary Item must match exactly the form and spelling of the pre-determined name, as shown in the middle column of the table.
By way of example; if you wish to use the item DisplayName, then your Data Dictionary Item must be named @ADUser.DisplayName as shown in this image.
User Properties - PoliceBox/Quvo Platform
The User Property is first defined in the Web Portal, the Manager role is needed for this, and the process can be found under the 'User Property Template' menu option.
This image shows a Quvo system example where users are allocated to a depot and a particular sector. The video goes through the steps to create a new User Property Template entry in the Web Portal.
- Access the 'User Property Template' option from the Manage menu
- Click on 'New User Property Template'
- Complete the 'New User Property Template' screen, it simply needs a name for the entry. See the section below on naming conventions.
The next step in the process is to create the respective entry in the Data Dictionary, in the App Designer. The video goes through the steps that are needed.
- Open the Data Dictionary tab and click to add a new data dictionary item
- Provide the name. The name must be typed in EXACTLY how it was typed into the Web Portal.
- Provide the field type, this is almost always 'Text'.
- You can then manage the data dictionary item. If you are certain that the field will always be pre-populated and/or you want to ensure that you collect information from the specific User, then it is possible to set the field to read-only so that the User cannot change the details at runtime.
In our example, we have followed the lead of the User Properties obtained from the corporate login account. Where the fields from the corporate login account are defined with a prefix of @ADUser, we have prefixed fields from the web portal with @User. This makes it easier to find and use such fields when adding them to your Task designs.
With the User Property Template entries fully established, Users simply need to login to the Web Portal for themselves and use the Self-Service area of the portal to enter their own information. Once entered it will begin to appear in the Client App, wherever employed in a Task design.
This video shows the whole process from start to finish.
Reset Login to see User Property updates quickly.
If a User has modified their User Properties in the Web Portal and wants to use the new information immediately, they will need to perform a 'reset login' in their Client App before they create a Task which requires the updated information (e.g. a change in telephone number). The reset login process also helps Users get updates (quickly) to their user group memberships, into their Client App.