the Schema properties define various behaviours of the Form for both it's configuration and execution.
The Name of the Form Type, which must be unique across all forms. This can be used as a filtering value in the Schema List page.
A text reference that can be used as a code for the form.
A category for the form that enables filtering in the Schema List page.
Th number of days from the creation of a form for it to become due, and thus the date that populates the construction page Due Date column. EG a Due Date of 3 days means the form will have a Due Date of it's Creation Date + 3 days.
An internal custom description for the schema. This is currently not exposed on the form and is purely for schema identification.
Show the Quick Navigation toolbar during execution for easy navigating between containers on a form.
Schema Permissions control user access to the form.
The user's Project Construction Roles are checked against the schema permission to determine whether they can Create or Delete forms of that type. Users must have 1 of these roles to be able to see the form listed in the project at all. In addition, the users Form Visibility configuration determines which of the project forms they can see once forms are created following these schema permissions.
The schema must allow at least 1 role to create it, in order to be valid and saved.
As an example, look at the table below and it's user permissions for Test Schema ABC1.
Looking at each of the users we can see:
- User 1 - Client - They can open, view and edit forms either created or assigned to themselves.
- User 2 - Contractor - They have no visibility of any forms as they don't have a Form View role.
- User 3 - Engineer - They can open, view and edit all forms on the project.
- User 4 - QA - They have no access to this schema at all.
- User 5 - Supervisor - They can open, view and edit all forms on the project.
Configure a value for the Form Description, used as a primary element to identify the forms.
Select any of the fields offered, which include:
- a number of default fields and
- any Single Line Text or Date controls in the form itself that have the Display in Header setting On.
Drag them to order the values and set any Delimiter character required between fields of the Description.
If a custom description is not set the default of <Schema Name>:<Creation Date><Creation Time> will be used.
Configure the Labels to show in the function toolbar during execution for Insight and Web viewed forms. Icons are shown for the buttons for Onsite viewed forms.
The buttons are:
- Save Form
- Distribute Form (Parent)
- Delete Form
- Create New Child Form (Repeat)
- Distribute Selected Children
Controls are the main building blocks you place in your form schema to collect and present data and attachments to the user during execution. These controls and each of their functions are defined by BIMXtra, but how they are configured and presented is defined by the form designer to suit a particular task or process on the project.
The controls are of 2 basic types; Layout controls determine the format and workflow actions of a form, while Data controls capture the forms information.
The basic division of a form is into Containers, which hold all the other available controls in a number of Rows. Controlling access to these containers, as individual parts of a form, is via;
- The user Role access of the container, and
- The Workflow Stage configuration of the container.
Each container configuration must have either:
- A Stage Sign Off, which completes that container, and increments the workflow stage of the form, or
- A Completion Sign Off, which completes that form and workflow steps, or
- It's Override Signature setting on and therefore does not require a signature. In this case container access is still controlled by the workflow configuration, but this container can't increment the workflow itself.
The Header of the container can be configured to show information about the form during execution. It can also be collapsed/expanded to show/hide the container contents.
The Footer of the container can show further information about the instance of the form as well as the form linking button and hyperlinks to any linked forms.
As well as a number of Common Settings a Container has:
The Title that appears in the Container Header by default. The header also includes any values of controls with the Display in Header setting on.
The colour of the Container Header, which can be defined as 1) Web Hex Colour 2) RGB value 3) HSL value. Use the sliders to adjust, or type in particular values.
Child Form Schema
Only 1 Child can be configured for a parent form, which can be at any workflow stage. The child form get's initialised at the beginning of the workflow stage it is set to.
A schema must already be published to be selected as a child schema and the parent is then connected to that particular revision of the child. If a child form is revised and republished then any parent forms should also be edited to use the updated child schema.
Importantly, the other properties of the child container, as defined by the Parent, are used when run from the Parent. Similarly, if the child form is run as a Standalone form, then it's own container properties are used.
Any container used for a child form must have it's Override Signature On in the parent.
Therefore although any form schema can be run as child to any other form schema, it is probable that parent/child schemas will be designed and configured to work in conjunction with each other. For example form location data can be inherited from a parent into it's children.
Display Room in Header
Display the RoomName value of the Form Location in the Header of the Container. This will be in addition to any other settings displayed in the container header.
Remove the requirement for a container to have a Signature as part of it's configuration. A container that does not have its own signature will be marked as complete when the workflow stage it is part of is completed.
A container used for a Child Form must have it's Override Signature On in the parent.
Collapse By Default
Set's the container to be normally closed as the form is opened in the UI. This is also known as 'Lazy Loading' and refers to the fact that the content of the closed container is not fetched from the server until such time that the user opens the container. The effect of this is to provide faster opening times for larger forms as only open containers need to be loaded completely as the form is opened. For a lot of forms this difference in loading time would be negligible and in fact this can be used as a preference feature. However, within the context of a Parent/Child setup, that may contain many children this could have quite a dramatic effect to opening times.
If a container is Collapsed by Default then it will be unable to show any Header preview features that require that container data until it has been opened by the user, at which time the header will update automatically.
Group Row Repeaters
Groups all the the Repeating Rows in a container into 1 action, such that they all get repeated with the single 'Add Another' action during Form Execution.
Show the Due Date of the form below the container heading. The Form Properties Due Date setting determines the form Due Date.
Show the Creation Date of the form in the container footer during execution.
Show the form Schema Reference in the container footer during execution.
Show the form Schema Revision in the container footer during execution.
Show the Project Name in the container footer during execution.
Show the form Schema Name in the container footer during execution.
Show the Form Reference Number in the container footer during execution.
Show the Form Linking button in the container footer during execution.
User Roles that can access this container and thus all it's content during the form's execution. Options allow the container to be Editable, Read-Only or Hidden.Configure the
Note, these are in addition to the the Schema Permissions, which control access to the whole form.
Controls are laid out in a form in a a series of Rows which are, in turn, held within Containers. There is no data, per se, associated with a row, it is purely a formatting device for other controls.
Rows are split into a number of columns to position multiple items on a single line. Rows are the responsive element of the forms, adjusting the layout of controls to suite the displaying device and screen.
As well as a number of Common Settings a Row has:
Number of Columns
The number of columns to split the row into and thus provide multiple positions for controls on each row. The row is split into equally spaced columns and will automatically adjust to best fit the form width. If the number of columns is too large for the form width the columns will automatically adjust to multiple rows instead.
Makes the Row a repeating row by providing a button below the row that let's the user add another copy of it during execution. The whole row is copied, including the column format and embedded controls.
The Group Row Repeaters function then repeats all repeating rows in the container in a single action, otherwise each row is repeated by it's own repeating button action.
The label for the Button to repeat the row, if it's a repeating row.
If Group Row Repeaters is on then the button label for the first Row Repeater in the container is used.
Allows you to add a static text to the form e.g. an instruction for the person completing the form or essential information they need to know.
Single Line Text
A single line of text.
The Single Line Text also has a number of Common Settings.
Multi Line Text
A Paragraph of text.
The Multi Line Text also has a number of Common Settings.
An option combo box. Allows a multiple selection from a group of offered values. When executing a form, the most selected options are automatically placed at the top of the list.
As well as a number of Common Settings a Combo Box has:
Set the number of tiers in Data Options.
For each tier, you can select:
- Single - only one option can be selected for that tier
- Multiple - multiple options can be selected for that tier
An option radio box. Allows a single selection from a group of offered values.
The Radio Button also has a number of Common Settings.
An option selector. Allows a yes/no answer to an offered question.
The Checkbox also has a number of Common Settings.
Allows the selection of a date and time.
As well as a number of Common Settings a Date has:
Link Due Date
When this option is enabled, this allows users to customise the form's due date.
When the due date is set in this control, this will override the due date set in SchemaProperties.
Allows the selection of a date and time of day.
The Valid Permit also has a number of Common Settings.
File or Photo
Allows the attaching of a file or a photo.
As well as a number of Common Settings a File / Photo has:
Option to set what type of files the form accepts:
- Images - Provides the ability to add images and photos to the form via the Camera or by Browsing the device,
- Files - Provides the ability to add files to the Form by browsing the device.
Both images and files can be uploaded straight from OneDrive to a form on Onsite.
Capture a signature, optionally using it to complete the container, increment the workflow stage and set the installation status of forms.
As well as a number of Common Settings a Signature has:
Set the type of Sign Off for the signature control as follows:
Stage Signature captures a user signature, name and company. Complete the current container and increment the workflow stage.
Sign off is not accepted until any controls that and have their Required setting on in all currently active containers are populated.
Sub Signature captures a user signature, name and company. It doesn't have any affect on the container or workflow, and multiple Sub signatures can exist in a single container.
Witness Signature captures a user signature. It doesn't have any effect on the container or workflow, and multiple witness signatures can exist in a single container.
Completion Signature captures a user signature, name and company, complete the current container and form, increments the workflow stage to completion and sets the Installation Status of the form. The completion signoff must be located in the last container in the form schema, which should only be active in the last workflow stage.
Child Forms have a Completion Sign Off as normal, and when executed in the context of a Parent, the child form is Completed and the Parent is unaffected. The Parent form must have it's own additional Completion signature.
Sign off is not accepted until any controls that and have their Required setting on in all currently active containers are populated.
Signatures set as Proxy Signatures, additionally accept a User Name in order to record those details against the signature rather than the currently logged in user. This enables a form to be signed off by someone who's not actively logged into a device at that time.
E.g. A Subcontractor may be required to sign a form being completed by a Site Representative on their device. The idea here is of a digital version of passing a clipboard to someone to sign.
Proxy Signoff can be configured for Stage, Sub and Completion signatures.
Default to Current User
In addition to the Proxy Signoff setting, the value can be set to the user editing the form at the time the signature control is active. This saves the effort of a user having to select themselves in order to sign off the form, but still allows another user to sign the form by selecting their accounts and proceeding.
Browser Password Auto-completion
Please note that Chrome based browsers have an auto-completion action, that will attempt to put values in both the PIN 'password' and an appropriate 'username' field automatically if both these options are on.
In other words if you have both Default to Current User and Signee Pin on you may get some unexpected default values in form controls, often a username that is saved in the chrome settings.
The user can always ignore these themselves, but in addition the browser settings can be set to not used saved passwords for your BIMXtra site.
Unfortunately there is currently no way to allow this function to be active for the main site login but not in the formbuilder application, thus leading to values being entered automatically in edited forms with active Signatures set up this way.
In addition to the Proxy Signoff setting, the Signee Pin setting enforces the user signing off the Proxy to enter their BIMXtra user Pin number before the signature is accepted. This provides a level of security to ensure that Proxy Signoff signatures are actually by the user whose details are captured.
E.g. A Site Manager can be assured that where his signature has been captured against a form, that it was he who completed it.
Print at Signoff
Saves a PDF print of the form to the DMS after it has been signed off. Each print revises the previous version of the DMS PDF and therefore a set of PDF files is built up as a record of the form at each sign off it goes through.
- For Stage sign offs, the default print is saved as the PDF.
- For Completion sign offs the default print is saved unless a Custom Print has been configured, in which case that is saved into the PDF.
The PDF is saved into the Published/Z. System Outputs/Form Signoffs/<Schema Name> folder.
Set's the Installation Status of any objects connected to the form which can be highlighted via the Insight Status Checker. Therefore a visual check of all objects and their Installation status' can be used to track progress on a project.
Collect a star rating.
The Rating also has a number of Common Settings.
A control that renders and actions HTML.
The link can be added when creating the schema or when the form is being executed. For the latter, the editable option must be set to Yes.
During runtime any clicked links will open in a new browser window.
The HTML control also has a number of Common Settings.
Repeating Row, except that this repeats a single control.A single control that can be repeated by the user as required. A button located below the control allows the user to repeat the control during execution. This has the same principle as a
As well as a number of Common Settings a Repeater has:
The control type to repeat, each with the same settings as their normal version. Valid types are:
- Single Line Text
- Multi-Line Text
- Combo Box
- Radio Buttons
- Date Range
The label for the Button to repeat the control,
A selection of Object data extracted from Design Schedules as required.
Define the schedule fields to be used, along with the text prompt labels to be shown in Data Options. Any schedule field can be added by referencing its system column name in the Schedule Field column. There are 4 additional system values that can also be referenced in the schedule field column:
- ModelName - The Model name of any selected objects.
- WBSArea, WBSRegion, WBSZone - The Area, Region and Zone values of the WBS code of any selected objects.
There is also an option to use UserFriendlyNames for the location values if Object Data is the configured Location Data source. There should be only one Object Data control per form, only the first one encountered will be considered during execution and there is a limit of 50 rows per Object Data control. Depending on other configuration items of the form, the object location values may also populate the Location columns of the form details view.
currently defined on the project. These are:A selection of Location Data extracted from Schedules as
During form configuration the control refers to these names, with the ability to set the 'Text Prompt' that the user will see instead of them. However, the project option to use UserFriendlyNames for these values will take preference over any custom Text Prompts when the form is executed. Configure and order the required columns in Data Options. There should only be one location data control per form and only the first encountered one will be considered during execution. Depending on other configuration items of the form the location data may also populate the location columns of the form details view.
A background image that can give context to form pin locations.
Add a table to your form.
As well as a number of Common Settings a Data Table has:
Customise the number of columns for the control.
Customise the number of rows for the control.
Details extracted from the current form instance such as Form Date, Due Date, Valid Period, Form Reference and Date, etc.
Common Control Settings
The settings listed below are general settings which are shared by more than one control:
A text label visible at the top of the control.
Default text to show in the control when the user has not entered a value. Can be used to provide simple help to the user as to required data.
The maximum number of characters to be allowed in the control.
A 'Tooltip' style message to display next to the label of the control.
When this control is run in a Child Form and Copy Data is set to Yes, the value of the previous child will be given as a default to the next created Child.
Determines if the control is required to be completed before Stage or Completion Sign Offs are accepted. Forms can be saved without these values being complete but they can't be signed off.
If a control is Required then a Error Message value is also provided which will displayed below the control if it's not completed at sign off.
A Red Star in the left margin during form execution indicates that a field is required.
If a required value is incomplete during an attempted Sign Off. it will be highlighted with a red boundary and text font and the Sign Off will not be completed.
If selected, the control must appear on print configurations setup in Print Designer. This does not enforce the printing of the form, only the fact that any custom prints of the form must include the control value.
Displays a standard comment box below the control, limited to 250 characters.
Adds the name of the person filling out the form, the date and the time at the time it was last entered.
Set the visibility of a control to be Always visible, or to be Only When the value of another control is set.
When Only when is selected, choose the Control whose value you would like to be conditional on, and enter the Value to check against. Valid conditions are:
- Is - The selected control must have the exact value given
- IsNot - The selected control can have any value except the value given
- Contains - The selected control must contain the value given somewhere in it's own value.
The special value Empty is the default, meaning the control has no user entered value.
Configure the predefined data values of a control.
Data values may be predefined defaults or user defined in the form schema. User defined values can either extract data from schedules or provide values within the form. Individual controls determine which data values are valid and thus the options available in this panel.
Enables a value to be edited by the user during execution. Locked fields can't be edited, while unlocked ones can.
Remove the defined data value from the configuration.
Adjust the ordering of the data values in the control.
Add another row
Add further rows to the data options.
Predefined defaults can be selected from the popup panel panel to select from, while user defined values will add a new row at the bottom of the existing panel.
Deletes the control.