App Designer Data Dictionary

Our platforms provide their own Data Dictionary, they promote an entity-relationship way of working and enable copy & paste of data around the Client App. Here's a walkthrough of the Data Dictionary.

What is this article about?

In this article we will look at the Data Dictionary.  This is where you define fields to model entities in your organisation.  Entities such as 'People', 'Objects', 'Locations', and Events.   You can model those entities in any manner of ways you choose.

Creating Field Definitions

When you create your fields, they can be based on an extensive range of data types.  Many of which you will naturally expect.   The Text data type is versatile and allows you to ensure information collected is numeric only or alphanumeric.  You can use Text data type to obtain email addresses.

Some of our data types allow optical character recognition to make data acquisition easier and other data types can be used to capture biometrics for searching purposes. 

Biometrics such as finger prints, or 1:1 facial recognition images, are supported.

You can apply data validation requirements, which ensures data is collected correctly:

    • Mandatory or Optional input
    • Formatting
    • Text style (lowercase, uppercase)
  • When you create your fields, you can provide context-specific help, which can be displayed to the user in the Client App, to help frontline workers understand how to collect information.  

When setting formatting (validation) requirements, this is done using regular expressions and we have provided a drop-down list of common formatting needs, from national insurance numbers to email addresses to help you make quick progress.

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.
  • A copy of the Configuration loaded into the App Designer.  This can be from either;
    • the latest version downloaded from the platform (File and Download)
    • a version previously saved (on your PC) that has not yet been published, to which you are returning
  • A simple Task that you wish to design. Conceptual or real.  Use it to define fields in your Data Dictionary

Data Dictionary Tab

We can begin by opening the Data Dictionary Tab.  Double click on its icon from the explorer window

Supported Data Types

The data dictionary supports a comprehensive range of data types, which allow you to collect information the way it needs to be collected.  The list of supported data types is shown here.


  • Allows the user to pick a date. 
  • The date picker displayed is specific to the device and its operating system. 
  • Field definition rules can be set to ensure the date is picked from a valid window.  For example, a date in the past for an event that occurred, or a date in the future when fixing an appointment.

When designing a business process, note that you do not need a separate date field when you want to capture the data a signature was obtained.  The Signature data type captures its own date within its meta-data, the benefits of this are:

  • Minimise the information collection process
  • Ensure the date is precisely that of when the signature was captured.


  • Allows the user to pick a time.
  • The time picker displayed is specific to the device and its operating system.


  • Allows the user to capture multiple fingerprints
  • Complex data type
  • Typically used to help identify a person, biometric--led searching
  • Could be used to capture elmination prints in a policing context

When deciding to use Fingerprints in your Task designs, you need to know that the platform supports the following Fingerprint capture technologies.

  • Integrated Biometrics (Watson)
  • Grabba
Photo-Only scannerless technologies will be included to promote widespread compatibility for fingerprint acquisition as well as reduce cost of implementing a digital-first strategy.


  • Complex data type that accepts a picture and a text-based caption.
  • Uses the device camera to acquire the image, or Image Gallery/Camera roll.
  • Two types of Image data type
    • Image - used for collecting Pictures i.e. Scenes, Person profiles.
    • Embedded - used for searching i.e. 1:1 facial recognition.




  • Media data type that allows audio to be recorded.  Clip size is up to 2 minutes.
  • Uses the microphone on the device to capture the audio


  • Allows a user to select an option from a group of possible answers to a question
  • List entries are known as 'Presets'.  
    • Large lists of Presets can be imported via the File menu
    • Equally possible to manage Presets in the App Designer
    • Presets held in the App Designer can be exported to a CSV formatted text file, use the icon at the top of the presets tab and follow the process.
  • A preset consists of
    • Short Text - displayed on small devices in the list
    • Text - the actual text displayed when a selection is made
    • Code - an alphanumeric code that a back-end system might need
    • Value - a numeric value that a back-end system might need
  • This image shows how to edit presets in the App Designer.  Double click on its entry in the presets list.  To remove a preset use the 'X' icon, to add a new preset use the '+' icon.


The password data type is an enhanced form of the Text data type.   It ensures that where it is deemed (absolutely) necessary to acquire a password (perhaps to perform a search against a legacy back-end system), that the password can be  obtained in a way that it is not revealed in the text box.

When the Password based Field definition is placed onto a Task design canvas, its role as a password capturing field is easy to see.



The signature is an incredibly significant data type in your platform.  With this data type you can collect a hand-written signature as part of the the information to be collected in a Task.

We don't need to give you too much imagery to help you understand, if someone provides their signature, it is done because that person is agreeing to, or is giving permission for an action to be taken.

This is what the field definition looks like, when it is brought into the Task design canvas.  Here we can confirm that the Signature data type not only collects the bytes of data needed to render the signature on your documents but it also collects the date & time when those bytes are collected.

But there's more to a signature in the platform than merely 'obtaining a squiggle'.   We have a collective responsibility to ensure that the information collected electronically remains precisely the same and not altered whereby the person who provided the signature can deny the authenticity of the information collected. 

This concept of non-repudiation is critical to the proper outcomes of certain business processes.  It is because of this, that when any signature is collected in the Client App, the fields of data to which it relates become locked (the presence of the signature means the values in those fields cannot be changed).   This happens at two levels.

  • When used in a Section (collection of fields) those fields are locked.
    • Helpful for a Police Officer signing-off part of a process
  • When used on its own in the final section in a Task design, the entire Task data is locked.
    • Allows a witness to provide their declaration of truth on an MG11 witness statement.

We will look at sections in our article on designing tasks.

Sub Form

There are two types of Sub Form data type  in the platform.   This is where we get to consider Task designs as individual 'jigsaw pieces' that can be re-used.  

  • Sub Form - Allows a Task to drop into a Sub Task within the Client App.  Allows the business process to model 1:many relationships e.g.  1 car, 4 passengers.
  • Inline Sub Form - Allows a Task to display a set of fields from the Sub Task as if they were actually part of the Task design itself. 

To put this into a little context, think about your wide range of business processes.  In each, there will be a set of entities from some core groups. i.e. Person, Object, Location, Event.  Here are some examples:

  • Object - Vehicle,  Tools, Weapons, Ingredients, Components
  • Person - Home-Owner,  Witness, Suspect, Victim, Case Worker, Police Officer
  • Location - Home, Office, Street Position
  • Event - Entry to a Scene, Theft, Accident

While there are common fields associated with each variation of the four common groups.  There will also be differences: 

  • Collecting information from a Home Owner (maybe the victim of a flood or other damage) might need different data from information to be collected about a Case Worker or a Police Officer.  
  • The location of a house will have an actual house number and street name, perhaps a post code but an anonymous position on a motorway might only have latitude/longitude data to go with the motorway name and perhaps 'between junctions'  descriptive text.

So, with Sub Forms it is possible to model your diverse data collection needs, based on the core types of entity and then re-use them wherever they are needed.

How do we create a SubForm?

  1. Create a Task Design (having first created the necessary Field definitions).
    Don't forget to save your work in the App Designer before going further.
  2. Create a new Field definition, either of SubForm or Inline SubForm.
  3. Use the earlier created Task Design as the source for the SubForm or Inline SubForm Field definition.
    Don't forget to save your work in the App Designer before going further.
  4. Drag & Drop the SubForm or Inline SubForm field definition onto the Tasks design(s) where those sub forms are to be used.



Allows a User to collect a web address, sometimes known as a URL.  The web address can become clickable so that the website is opened in the web browser.  


The Location Data Type allows the User to collect a precise location while completing their Task.  It might be the exact location of an Accident, or an asset installed at street-level (i.e. water hydrant). 

The Location in this field can be set even when the User is not physically at the location being specified. 

The Location data type supports What3Words, which has widespread use including among emergency services organisations.   Allowing Users to supply just three words in the form of to identify a location to a precision of 3m2.


Perhaps the most versatile of the data types in the platform.  The Text data type allows the User to capture text responses to questions

When used in conjunction with Validation and Formatting settings, the Text data type can be used to collect lots of different types of data:

  • Standard alpha-numeric text
  • Numeric values (integers, floating-point, etc)
  • Specialist strings (email addresses etc)


On the face of it, the Yes/No data type seems to be a simple way to get answers to simple questions.  Many contexts of the use of this data type, this simplistic use case will be true.

But when used to help the user collect just the amount of




Field Definition Settings

When you create a Field definition within the Data Dictionary, you will see there are several settings, common to each data type.   Their meanings are explained as follows:


It is possible to import data into the Client App, from another (including 3pty) App on the same device.  This setting allows you to define the field name that is to be received from the other App.

Flexibility in this respect means that you can have your other App developers integrate into the Client App, using the general message passing specification that we specify, but can name fields to suit the context of the message being passed to the Client App.

If the Field Definition is not to be used for any form of cross-App data sharing, then leave this setting empty/blank.


An alternative field definition name can be provided, which (if required) can be changed in the Task design canvas on a case-by-case basis. 

When creating the Field Definition within the Data Dictionary, it is possible to stick with the same text used to name the Field definition.

That same text will be automatically entered into the AltFieldName setting for you.

So why have an AltFieldName?

  • Allows the use of the same Field definition more than once on the same Task design canvas.   Each use of a Field definition on a Task design canvas must have a unique AltFieldName reference.
  • AltFieldName is the 'go to' setting for matching when it comes to mapping fields with back-end systems (Connectors) at runtime when performing Search requests, or Exporting completed Tasks.
  • When you drag & drop a Field definition 'placeholder' onto a Word document template (for Exporting completed tasks to documents) the placeholder is formatted with the AltFieldName reference to ensure uniqueness.

Default Prompt

This is the prompt that will be used (as a default) whenever you drag the Field definition onto the Task design canvas.

When it comes to using the Field definition on a Task design, the prompt will be used.  

There may be occasions where the Field definition must be used on a Task design, but the prompt needs to be changed, either because the context of use is slightly different, or the wording is fixed because of legislation.   In such situation, the prompt can be changed, from the default, on a Task design basis.  Simply amend the prompt in the properties window on the Task design.   There is no need to create unnecessary Field definitions.

Help Text

Allows you to set 'context' specific help text, which will be displayed to the user in the Client App.

The help text can be assistive to a User in guiding their completion of a Task, especially if they've not completed a Task (of that given design) in a while.

Help text can also be assistive in reducing training overhead to Users.

Regular Expression

Regular Expressions are part of the information collection 'validation' regime.   When a regular expression is applied to a field definition of a Text data type, it can ensure that the data is collected in a way that it can be properly understood, usually by certain back-end systems or back-office processes.

The use of regular expressions conforms to the Microsoft .Net methodology.  The language reference is available on the Microsoft Website although it can be a little technical in nature.

Often, there are common values you wish to acquire within a Task, an email address is a good example.  To assist in applying regular expressions quickly, we have added a 'picker' screen, which is available from the button '...' (ellipses).

To apply the regular expression, click to select the relevent one from the list and click OK.  The regular expression text will be inserted for you.



Default Text Value

Allow a default value to be set.  Incredibly useful for Task designs where  you want the User to enter the date and the User finds that having "today's date" pre-populated is helpful to them.

It is possible to enter any text into this box.  You will also note that this setting also hides a drop-down list. 

The drop-down list allows you to select specific values known to the Client App, each of which relate to date or time.

Keyboard Mode

This allows you to set the keyboard mode, relevant to the type of information you want the User to collect in a specific Field definition.

While this feature is largely dependent on device compatibility, it is possible to set the keyboard to help the User speed up their information collection.

If you require an Email address, the keyboard will be switched so that '@' and possible '.com' buttons are available.

If you expect that the information will be exported to a back-end system which requires it in upper-case, you can set the TextCaps option.

Alternatively, if you require only a numeric input (i.e. cash value) then you can set the numeric keyboard for display - and possibly use a regular expression in collaboration with this setting to absolutely guarantee numeric values. 

Default Style

This is another way to ensure that information is collected in a way that it can be immediately delivered to and consumed by the back-end system.

If you require all 'uppercase' text, then set 'ToUpper'.  'CapFirst' will capitalise the first letter on each sentence. 

CapsNoSpace is precisely that. All upper case text.  No 'space' characters are permitted, either.  Great for capturing code-values.

Although, if you really want code-values, perhaps from a selection of possible codes (e.g. fixed penalty notice codes), then it may be prudent to consider the List data type instead of a Text data  type.

Max Length

Really useful for Data definitions with the Text data type.  If your User needs to input data, but provide no more than a few characters, this setting will help ensure that. 

The setting can also be used in conjunction with regular expressions and of course where numeric (e.g. floating point) values are required.


Stuff you need to know.

Here's some tips about the Data Dictionary and Field definitions which will help your understanding.   Some of the rules within the App Designer are there to ensure that data is properly managed throughout the platform.

Save your work

It is not uncommon to want to use a Field as soon as it has been defined in the Data Dictionary.   But you must first save your Data Dictionary before it can be used.  

Removing a Field Definition

You cannot delete a field definition if it is being used anywhere.   If you are considering removing a field definition, go into the Data Dictionary Designer and right click the field definition from the list.


If the Field definition is in use, it will be listed under 'Dependent Form Designs'.   Once a Field definition is no longer in use, the 'delete' option will not be greyed out. 

User Properties - Incorporate information from the User's profile

You can create (Text) data dictionary items, which will take their default value from the user's profile.  These are known as User Properties.   

User Properties can be derived from two sources, and they can be combined:

  • User's Active Directory or Google Logon Profile (Corporate account)
  • User's PoliceBox/Quvo profile.

To learn more, to to our article on creating User Properties.


Return to App Designer Familiarisation