Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Follow best practice guidelines and considerations when using Calculated Properties.
Follow these best practices and considerations when using Calculated Properties in Screens:
Calculated Properties are not designed to modify the current Screen control value(s). Calculated Properties read the value(s) from a specified Screen control via its Variable Name setting to calculate a result.
When designing a Calculated Properties, do not use the value from a Screen control which, in turn, calculates that property. Such design is circularly referencing the control from which to calculate its value.
Calculated Properties are not designed for a user to modify a Calculated Property via a Screen control.
When referencing a Calculated Property in a Screen, use its name in the exact case as defined since a Calculated Property's name is case sensitive. For example, netCost
and NetCost
are two distinct names for Calculated Properties.
Calculated Properties are not designed to introduce additional JavaScript functionality: doing so can cause instability in that Screen. ProcessMaker Platform does not support Screens that have additional JavaScript functionality within them.
Do not use third-party libraries within Calculated Properties such as jQuery or moment.js, as these libraries may be updated in and/or removed in ProcessMaker Platform. ProcessMaker Platform does not support Screens that use third-party libraries within them.
Do not reference one Calculated Property within another, such as referencing this.myCalcProp
in a Calculated Property named myCalcProp
: doing so causes a circular reference which degrades the performance of the Screen or may cause the Screen to stop functioning entirely.
If using a Calculated Property in a nested Screen that requires the value from its hosting Screen, then do not use the same Request variable in the nested Screen’s Calculated Property as that used in the hosting Screen.
Calculated Properties are generated values that cannot be edited after calculation.
Follow security best practices to better secure your ProcessMaker Platform instance.
Follow these best practices to enhance security in your ProcessMaker Platform instance:​
Require all users to periodically reset their passwords.
Require all users to log on to your ProcessMaker Platform instance via Single Sign-On (SSO), OAuth, OKTA and/or two-factor authentication.
Follow these guidelines:
Configure SAML SSO or another ProcessMaker Platform-supported SSO authentication protocol.
Instruct all users to authenticate via SSO to log on to your ProcessMaker Platform instance.
Verify that all user accounts that run scripts are valid and appropriate.
Follow these guidelines to identify invalid and blacklisted IP addresses that access your ProcessMaker Platform instance:
Ask your Customer Success Manager to provide a list of all IP addresses that access your ProcessMaker Platform instance.
Identify the following from the list of IP addresses:
Identify which IP addresses on this list are invalid.
Identify which IP addresses are blacklisted.
Provide your Customer Success Manager an incident report.
Follow best practices when using Collections as the "source of truth" for business data in your organization.
As a best practice, use Collections to maintain your organization's business data as its "source of truth" from which Processes and their Requests read and edit. Do not use Processes, and the Screens in which those Processes access, to store and maintain business data. Collections are designed to maintain business data outside of Requests. There are several advantages to following this best practice:
Request participants may not be business stakeholders, and vice versa: Configure Collections permissions for users or for groups who may view, edit, or delete records in each Collection. These users/groups can have access to business data without participating in Requests. Inversely, those who may change specific information within Collection records may not be business stakeholders to view all information in Collection records.
Business data can exist outside of Requests: Since Collections are the "source of truth" for your organization, this information may exist prior, during, and after Requests exist.
Separate Process design from your business data: By maintaining business data outside of Requests, there is a separation between Process design and the "source of truth" of your information. The Process may change or be archived, but the business data from which Requests access exists outside of those Processes.
Use Requests as an audit log how your business data changes: Maintaining your business data in Collections makes auditing your information easier because there is a digital accounting of how your business data changed via Requests.
As a best practice, use Requests to edit Collection data. Do not edit Collection records directly from within the Collection. By using Requests to edit Collection data, your organization maintains an audit log of your business data via Requests.
Follow best practices when designing Decision Tables.
Follow these best practices when designing Decision Tables in Decision Table Editor.
String
Data TypeWhen using the string data type in an output column that displays quotation marks intended as punctuation in the output, do the following to avoid an error while processing that data:
Precede each quotation mark intended as punctuation in the output with a backward slash (\
) to indicate that this character is intended as punctuation and not to denote the beginning of the string output.
Place a space (
) between the last quotation mark intended as punctuation and the closing quotation mark that denotes the end of the string output.
Example: "\"This is text to display verbatim.\" "
When adding a decision, the decision expression's format is enclosed in double quotes as long as it is necessary to do it. This format does not work in complex expressions where using the dash (-
) character to define a default option or functions like substring
, which do not need to be enclosed in double quotes.
Consider the following best practices and considerations when designing dashboards for your business stakeholders.
Understand what information your business stakeholders need to either take action on information or make that information easier to do. Understanding what your stakeholders need guides you in how to design the Display-type Screens to provide that information. Consider the following examples.
Prior to creating a dashboard, ensure that the following ProcessMaker Platform assets exist for a dashboard:
A Display-type Screen must contain the content for your dashboard. If the specific Screen for this dashboard does not exist, create that Screen.
While a dashboard may contain any content that a Display-type Screen supports, consider any of the following for an effective dashboard:
Design Business management information (BMI) and key performance indicators (KPI) for intended business stakeholders. Create one or more Saved Searches, and then design Saved Search charts from the Saved Search(es) to provide KPIs that your intended business stakeholders would inform them of business information they would value.
Design content in that Screen that this dashboard's intended audience would find valuable, including but not limited to general information, files to download or preview that this audience uses frequently, and images. Integrate information from a Collection record to provide relevant record data.
Design the Screen as intended to display the dashboard's content. Consider the following when choosing the chart types:
Line charts: Use line charts to plot data points over a period of time. They are compact, clear and precise. Line charts format is common and familiar to most people so they can easily be analyzed at a glance.
Bar charts: Use bar charts to divide your data into neat categories. These charts are easy to understand, clear, compact, and have multiple use cases.
Pie charts: Although pie charts can be visually scanned easily and stakeholders notice the biggest slice immediately, challenges in terms of scale may result in the smallest slices being so small that they even cannot display.
Keep the layout and order of information in mind. Follow these general design principles for stakeholders to more easily assimilate dashboard information:
Key information should display first, preferably in the top left region of the page. This mimics how written words are traditionally parsed. Research has shown that users will initially look to that area of a page when it has loaded.
Major trends, data points, and the most important tasks should be visible at a glance. After displaying the initial overview, provide more granular information.
Group charts, metrics, and functionality by theme with comparable items placed next or near each other.
Consider the following best practices and considerations when designing custom menus for your business stakeholders.
Generally, when a user cannot access a ProcessMaker location or asset, ProcessMaker Platform displays Unauthorized to that user.
Ensure that all users/group members that use the menu or redirect to a Collection have the following:
Follow these guidelines and best practices when building PM Blocks.
Every PM Block must have one of the following Start-type events in its Process model:
Only one Start-type event may be used in the Process model for a PM Block.
Make your PM Block easily recognizable for designers to use.
Make your PM Block distinctive from other PM Blocks in the PM Blocks tab of the Explorer panel.
Follow BPMN best practices to design dynamic business solutions.
For each example, the Bad Practice tab displays by default. Click the adjacent Good Practice tab to view the best practices to follow. These practices cover the following design aspects of a business process:
Before beginning the actual development of a Process, clearly define the scope of business requirements using the following guidelines:
Why: Clearly define the purpose of a Process. If the Process is replacing an existing one, document the problems encountered in the current Process. This will ensure that the new Process being developed resolves all issues currently being faced.
Who: Define the participants of your Process. This includes internal and external users and stakeholders.
What: Document the intended outcome of the Process. Define the expected results and the targets to be achieved.
Use a descriptive name for a Process that concisely defines its purpose. Avoid using the name of your organization in the Process name, but instead, highlight the business requirement the Process fulfills. When naming a child Process, use the parent Process's name to highlight the relationship.
An inconsistent direction of flow makes it harder to comprehend the Process model.
A clear left to right workflow makes it easy for a viewer to understand the Process model.
Every Process must have at least one clearly defined default path. This is the path that an instance of this Process follows when there are no errors or exceptions. In ProcessMaker Platform, an instance is called a Request. After defining a default path, configure alternate paths for error handling.
Instead of creating one large Process with many Tasks, simplify Process design by dividing the Process into sub processes. This action not only helps design more efficient Processes, but also streamlines error handling and maintenance procedures for these Processes.
Do not create a Process without at least one Pool element.
Use at least one Pool element in every Process.
Do not leave a Lane element within a Pool element empty. If steps do not fit into a Lane element, remove that Lane from the Pool element.
Place every element clearly within a Lane element. Process elements should not be placed on Lane boundaries.
Do not place Process elements on Lane boundaries.
Every Process element must be clearly contained within the boundaries of its Lane.
Use a verb to describe the work to be done and a noun to describe the object on which this work is being performed. For example, Review Contract
, Manager Approval
and Send Booking Details
.
If there is a need to use two verbs to describe the Task, consider splitting it into two Task elements.
When sending files through a Script to an external database like ProcessMaker Intelligent Document Processing (IDP), the Request ID becomes essential. To ensure smooth functionality, it's advisable to follow these steps:
Copy the URL of the Form Task and paste it into the Redirect URL setting of the Start Event. The redirection will occur when all files have been uploaded.
Trying to configure the Request ID within the same Form-type Screen used for uploading files in the Start Event element will not work correctly. This is because the Request ID is generated after the form is submitted. Therefore, it becomes available in the form opened using the Redirect URL setting.
Use a verb to describe the action, a noun to describe the task or subject and a question mark to indicate a pending decision. For example, Application Approved?
and Resend Notifications?
Use a brief interrogative statement to clarify the purpose of a Gateway. For example, Is Start Date > 30 days?
Use a Gateway element whenever a business decision requirement occurs in the Process workflow.
Absence of Gateway elements makes the Process look disorganized.
Proper use of Gateway elements for branching makes the Process flow clear and organized.
This Process is incomplete without an End Event element.
The presence of Start and End Event elements clearly define how/when the Process starts and ends.
When using more than one Start or End Event element in a Process, name them uniquely to clarify their purposes.
Using the same name for multiple Start Events creates confusion regarding their purposes.
Multiple Start Event elements in this Process have been labelled uniquely to depict their purposes.
Differentiate the use of Signal and Message type Events in all Event-type elements. Avoid using Signal-type events for design situations when the purpose is to send only a message in a workflow. As a best practice for this use case, use Message Events instead of Signal Events.
If using the Interrupting setting in a Boundary-type Event element, except Boundary Error Event elements, as a best practice use a "dummy" Task ("Trash" in the example below) to store interrupted Tasks caused by the Boundary-type Event element.
The Script Task element runs each time the Intermediate Timer Event element triggers until the Exclusive Gateway element's condition is met. However, if the condition is not met and the loop continues for an extended time, ProcessMaker Platform errors often occur when accessing the Request through the user interface, such as a Task.
To avoid this scenario, add a counter to control iterations. For example, the next design shows that the counter can not exceed more than nine iterations to run the Intermediate Timer Event. If the timer is set to run every hour, then, it will be escalated to a task that an administrator can handle to not exceed nine hours.
Follow best practices when designing Screens.
Follow these best practices when designing Screens in Screen Builder.
It is also helpful to establish a variable naming convention with all Process Owners in your organization. For example, use a naming convention such as <screenName>_<controlName>
.
Use the Tab Order setting to coordinate the keyboard navigation order, determining the sequence in which a control takes focus among other controls in a Screen. When the tab order for a Screen's controls is designed well, that Screen navigates via keyboard in the logical and intuitive structure of that Screen's content.
Follow these best practices to set the tab order for a Screen's keyboard navigation:
The tab order should follow the visual flow of the page: left to right (for Western readers), top to bottom.
Set the first control's tab order to 1
.
Set the number for each subsequent control the sequential order that each control takes focus in the keyboard navigation order. Consider the following example.
Set the tab order for these controls as displayed from top to bottom as follows:
Set the tab order for all applicable controls for the best Screen usability experience and to avoid unexpected usability.
Use the same CSS Selector Name value on different controls of the same type to apply the same custom CSS style to all those controls.
Configure the Select List control to get the JSON object of the array, not only values.
Within the Loop control, duplicate the JSON object so that JSON object elements match those of the Select List control's.
Consider this example. The following is a JSON object that contains the JSON array from which a Select List control could use as its options when configured to reference the JSON object.
For optimal Screen performance, as a best practice use fewer than 25 controls in one Screen. When adding more than this number, a warning displays.
Follow these best practice guidelines regarding the use of single-value JSON objects versus JSON arrays to reference Select List control options from Request data:
Therefore, to use a JSON object that contains all Select List control options, ensure that none of the following would occur to the Request data from which the Select List control references its options:
Ensure that none of the values in any of the individual JSON objects would modify in any way.
Ensure that empty values are transformed to null
. ProcessMaker Platform cannot accept empty values as options in Select List controls or Collection records.
If you select the Object option, which reads the entirety of a JSON array or object instead of one value, ProcessMaker Platform expects the selected Select List control option to match that of the Collection record. However, when the Select List control is first selected by the user to view its options, the Select List control contains a different value, thereby causing an error.
Avoid the following practices when designing Screens in Screen Builder.
Avoid adding custom JavaScript when designing Screens for the following reasons:
Custom JavaScript implementations are not under the ProcessMaker Platform Support scope: Because custom JavaScript implementations are not under the ProcessMaker Platform Support Scope, Support agents will not support custom JavaScript implementations.
Custom JavaScript implementations creates an unmaintainable business solution: By introducing custom JavaScript into Screen design that may affect workflow routing behavior outside of that Screen, you make that business solution much more difficult to maintain.
During a Request, a JSON object's value changes while routing.
The Request may reference Collection data that has changed since the Request started.
It is not good practice to store all data in one variable of type object
because any of the attributes can be modified at any time.
Instead, reference Request data that in which all JSON objects are peers of one another.
Note that this practice to avoid does not affect when you are providing your own Select List control options or using a Data Connector to get options.
During a Request, if the second option in the Select List control is selected, Dmitri Shostakovich, then the current Request data is as follows:
When the Screen containing the Select List control accesses the Request data to get its values from the Composers
JSON array, the second JSON object is different. Therefore, the Select List control contains no options because the Composers JSON array is not identical to the object stored in the ComposerSelected
JSON object: ComposerSelected
contains the address with Moscow
, while the Composers
JSON array contains Petersburg
.
This example demonstrates why it is a bad practice to store JSON objects in which their values may change dynamically within other JSON objects.
Following this configuration, when the Select List control references the id
JSON key name, then the current Request data is as follows:
If any of the JSON objects in the Composers
JSON array change, the Select List control references a key name in the JSON object does not change. Therefore, the Select List control displays options derived from the Request data.
Consider the following when designing custom . When configuring a menu, ensure that your business stakeholders have access to each link's location. For example, ensure that business stakeholders have appropriate user and/or group permissions that allow them to access to destinations. Many of the following considerations also pertain to configuring which or when they next log on.
Ensure that each user that may access the link that starts a Process's Request is element to start a Request from its Process.
See .
, as configured from a user's account or a group
Access to at least view the records in that Collection, either as or as
See .
Ensure that all users/group members that use the menu or redirect to a Saved Search have been .
See .
Follow these guidelines when building .
When , in the Name setting, specify the label for that PM Block when it is placed into a Process model. This label is different than the name of the PM Block as it displays on the PM Blocks page.
When , in the Start Event Drop Down setting, select the Start-type event that triggers that PM Block. Without this setting configured, the PM Block never triggers regardless of the conditions in that Request. Therefore, this is a required configuration.
As aa PM Block author, add an icon when for the following reasons:
Follow these BPMN best practices to that not only showcase a stunning design but also help increase the efficiency of your organization.
Bad Practice | Good Practice |
---|
Maintain a consistent left-to-right direction for elements and avoid crossing lines. This makes a Process map well-organized and easily readable for all stakeholders.
While it is recommended to use horizontal (left to right) Sequence Flow elements, use vertical elements to send messages across different elements.
Use the elements to clearly label and define the purpose of different elements in a Process.
As a best practice, use at least one element in a Process model. Organize BPMN elements within this Pool element to indicate the default and alternative workflow paths. Each Pool element in a Process model constrains workflow for an incident of that Pool element, called a . Moreover, it provides a concise workspace for Process designers to organize all Process elements.
elements clarify the participants in a Process and provide a pictorial representation of how tasks are distributed amongst teams or personnel in your organization. Each Lane element indicates a role, actor, or participant within the Pool element.
Use a descriptive name for all Task-type elements which clearly defines the work being performed in these Tasks. Task-type elements include , , and . Follow these naming conventions:
While dependent elements must run sequentially, run non-dependent Script Task elements in parallel to optimize time for each incident of that Process. An incident of a Process is called a Request.
Create a as a .
Assign a Screen to the Start Event element for uploading files.
Create a element as a .
Assign a Form-type Screen to the Form Task for processing the uploaded files via a to call the Request ID.
Web Entry settings are not supported for a task configured to use . For more information, see .
Use descriptive names for elements to help clarify their purpose and their role in the business logic of a Process. Follow these naming conventions:
Use one Gateway element to split the Request workflow and another to join it. Do not divert the workflow back to the splitting Gateway element. Moreover, use the same Gateway-type element to split and join. For example, when using a element to split workflow, use the same type of Gateway element to join it.
Every Process must have at least one element and one element to clearly define the beginning and the culminating elements of a Process.
After adding a element, as a best practice avoid using an because it closes the Request without sending the Signal.
As a best practice, avoid modeling a element's result to be evaluated by an element, and then returned to the Script Task element on a timed interval set by an element.
Use elements to provide a brief notation for general descriptions, Process logic, and exception handling. However, Text Annotation elements should be used in moderation and for brief information only. For detailed information about Process elements, use the features available through the Documentation panel.
The Advanced Screens package deprecated in March 2021. If you use the Advanced Screens package, please contact your Customer Success Manager. .
Request variables store a control's value during a request and are defined using the control's Variable Name setting. Use a unique Variable Name (where applicable) to avoid overwriting the value of screen controls during requests. It is recommended to preview with JSON data model in .
Control Label | Tab Order Number |
---|
If a Screen control affected by a is hidden by default from , the visibility rule overrides the custom CSS design. For example, if custom CSS is designed to hide a Screen control by default when that control's visibility rule dictates that it be visible, the visibility rule overrides the custom CSS to display that control. As a best practice, use visibility rules instead of custom CSS to hide a control by default.
When using a control that gets its options as a from a , and that Select List control is used in a control, follow this best practice:
Download and then the following Screen into Screen Builder. the Screen to observe how the Select List control functions within the Loop control: select an option, and then enter values. Observe the JSON array that displays in the Preview panel.
Use or divide your Task into multiple steps to avoid creating large Screens that adversely affect performance. Alternatively, use the Page Navigation control to create a multi-page Screen. .
As a best practice when a validates the JSON in a Screen for a datetime value, use a control instead of a .
As a best practice when using HTML escaped characters like &
, <
, >
, /
, “
, '
, `
, or =
, use triple mustache brackets to avoid displaying incorrect values in Screen controls. Example: {{{name_with_character}}}
For more about mustache syntax, see .
As a best and general practice, use single-value from which to reference Select List control options instead of a that contains all options within an array of objects.
If any value within the JSON object that contains all Select List control options change, such as via , then none of the Select List control options display when a user clicks that Select List control.
As a best practice, when editing a record using a in a , configure the Select List control's with the Single Value option. This best practice applies only to this use case.
When using a single value from which to select a Collection record, ProcessMaker Platform does not have this expectation. See section in Select List control settings where this setting applies to this use case.
that use as their Source can adversely affect your Screen's performance. Therefore, when defining such Watchers, a warning message displays.
Use Scripts sparingly with your Watchers and consider other alternatives when possible. For example, instead of using a Script to call an API, use a to connect to the API. Afterwards, use this Data Connector in your Watcher. .
When configuring controls to reference for their options, avoid using JSON data in which a contains its own JSON objects that may change dynamically. The value of any JSON object may be changed dynamically in the following ways:
Consider the following in a control called Composers
that contains two . The at this moment in the Request is the content of that Record List control as a JSON object.
A Screen contains a Select List control with a Variable Name setting value of SelectedComposer
. This Select List control follows the by referencing the Composers
JSON array to return type Object.
See these sections in that document the settings described above:
of SelectedComposer
of Composers
If a modifies the Record List values, the JSON objects in the JSON array have changed from the original values that Select List recognizes. For example, suppose the address in the second JSON object changes in the Record List control: Moscow
has been changed to Petersburg
.
Instead of following the , configure the control to store a and reference the id
JSON key name in the Variable Name Property setting because its value is not likely to change.
Stakeholder Need
Design Guidance
Manager needs an overview of team progress and status.
Include Save Search Charts that show Request and Task status and when each started to provide insight on team member progress.
Team starts Requests for the same Processes frequently.
Use Rich Text controls with "button" images that link to Processes that may be started via Web Entry. See Locate the URL to Start a Request Via Web Entry.
Employees need information and files.
Design a homepage or portal that provides employee information and files employees may download via File Download controls.
MyBank Loan Process | Residential Loan Application |
The HR Process | Employee Onboarding |
Training Sub Process for HR | Employee Onboarding - Training Request |
First Name | 1 |
Middle Name | 2 |
Last Name | 3 |
Submit Your Name | 4 |
Follow best practices when designing Vocabularies.
Consider the following guidelines and best practices when designing Vocabularies:
Upload your JSON schema or design in ProcessMaker Platform: You may design your JSON schema before you create your Vocabulary or design it in ProcessMaker Platform. ProcessMaker Platform provides a graphical interface in the Visual tab of a Vocabulary that non-developers may find easier to design a Vocabulary. This may be helpful if you are not familiar with coding a JSON schema but understand the design compliance your ProcessMaker Platform assets must meet. If you are familiar with designing JSON schemas, you may code your JSON schema in the Code tab. Changes made in one tab reflect in the other tab.
Vocabularies designed in ProcessMaker Platform are named mainSchema
: If you design Vocabularies in ProcessMaker Platform instead of uploading one when a Vocabulary is created, the root name of the Vocabulary is mainSchema
. mainSchema
represents the top of the JSON schema object and contains the properties of that Vocabulary. If you upload your own JSON schema, its root name remains unchanged. JSON schema root names must begin with a letter, followed by any number of letters, integers (0
through 9
]), hyphens (-
), underscores (_
), colons (:
), or periods (.
).
Design your Vocabularies modularly: As a best practice, design your Vocabularies as segmented, minimal pieces rather than large encompassing JSON schemas. Small, modular Vocabularies can be re-used across multiple ProcessMaker Platform assets for a variety of Processes and business solutions. More specifically, Vocabularies can inherit their properties from other Vocabularies to build on one another, yet extend from those inherited Vocabularies.
For example, a Purchase Request Process may require billing information as well as shipping information. These groups of information may be designed in segmented, separate Screens modularly and then incorporated into a third Screen that uses Nested Screen controls to incorporate these segmented Screens for easier re-use and maintenance. Likewise, each of these Screens may use its own Vocabulary to validate required and conforming information for each. As a different design approach for this example, the Vocabulary that validates the shipping information may inherit the Vocabulary for the billing information, thereby referencing its JSON schema properties for easier maintenance; while referencing the Vocabulary for billing information, the Vocabulary for shipping information contains its own properties for validation and compliance.
Define properties in your Vocabularies in the order as intended: If you design your Vocabulary in the Visual tab, define its properties in the order from top to bottom as intended. Properties cannot be sorted in a different order than how you create them. However, you may view your Vocabulary in the Code tab, which displays the JSON schema as code, and then reorganize properties there.
Ensure the maximum length of each property is not 0
or a negative number: Except for the root of the JSON schema, such as mainSchema
, each property in a JSON schema and Vocabulary must have a length that validates how many digits, whether alphabetical, numeric, or alphanumeric, that validates conformity of data for that property. ProcessMaker Platform stores a property's length using the maxLength
key name by default to define the maximum number of digits that property's value may contain. For example, a person's age may contain no more than three (3) digits. Ensure that each property contains at least one (1) digit. To specify a minimum digit length of a property, select the Code tab and enter that minimum length using the minLength
key name. To specify an exact number of digits, use minLength
key name. For example, a credit card number must contain 16 digits.
Follow best practices, and avoid worst practices, when designing Form-type Screens.
Follow basic form design best practices so your Form-type Screens are easy to navigate and read. Many of these best practices may apply to Display-type Screens.
Use Multicolumn / Table controls to organize the layout and width of other controls.
For each example, the Bad Practice tab displays by default. Click the adjacent Good Practice tab to view the best practice to follow. Design practices that are similar are grouped into the following sections:
Avoid using placeholders for Line Input controls. When users start typing in the controls, the placeholders disappear.
Use labels in controls to indicate their purpose, since they are always visible for users to see.
See the Label setting for the Line Input control for more information.
When a user navigates through a multi-column Screen, making the user follow a Z-pattern is more difficult for the user's eyes. Users might not even know where to start.
If the Line Input controls associate with one another, place them in one horizontal line.
If your form is large, do not use all Line Input controls in one section.
Use the Rich Text control to add headings that break the form into logically-related groups.
Avoid text redundancy as shown in the example below.
Be as concise as possible in control labels.
If there are fewer than four options, as a general guideline do not put them in a Select List control as drop-down options. This design requires the user to click twice to commit an action: once to display the Select List control options, another select an option.
If there are fewer than four options, show the options immediately using Submit Button controls. This design requires one click to commit an action.
By providing no user guidance for information to enter into the form, users become confused.
Use helper text to provide context how to interact with each control.
Unmasked Line Input controls allow users to introduce errors when entering commonly-used information.
Use masking patterns to pre-format commonly used information, thereby allowing users to enter information accurately. See the Custom Format String setting for the Line Input control for more information. Click the image below to enlarge.
Entering the following Script code for a Record List control without Row IDs does not work as expected such as allowing to edit, delete, or add records.
When initializing a variable for a Record List control in a Script code using a Calculated Property, it is essential to ensure that each row contains not only the record attributes but also a unique row_id
attribute. This row_id
should ideally be a hashed value or a unique string for each row. The presence of this row_id
is crucial for internal row tracking. For example, if we have a Record List control of first_name
and last_name
, the Calculated Property should return something like this: