Form steps and pages

Steps and pages are the basic elements of the form structure in Eximee Designer that allow organizing multi-step forms. Step groups one or more pages and represents a logical stage of the form (e.g., the stage of collecting company co-owner data, borrower income data or the application summary), and page is a single screen/subpage containing specific fields and components. The designer thus defines the user's navigation path – sets the order of steps, the pages contained in them, and the conditions for their display. In the user interface, steps can be indicated using a progress bar (so-called steps bar) – its visibility is configured in the Properties.

Steps tab – editing the form structure

The steps and pages structure is managed in the Steps tab of the application editor. After opening the form, this tab is displayed by default in preview mode (read-only). There you can see the list of all steps and their pages – for each element the following is shown: business identifier (mid), title (if assigned) and visibility condition (a conditional expression that determines whether a given step/page should be displayed). Note: these conditions are not executed in this view, only presented for information.

To edit the structure, switch the Steps tab to edit mode (the “pencil” icon – Edit process) – it may be necessary to release any draft lock on the form first. In edit mode you can add and remove steps and pages, edit their basic properties, and change the order using the drag & drop Remember a few rules:

• You cannot delete all steps! – the form must retain at least one step.

• Adding a new step automatically creates a new page within that step (a step cannot be empty).

• Deleting a step removes all pages it contains.

• Moving pages between steps is done by dragging with the mouse. For example, you can drag a page from one step to another.

• Deleting individual pages or steps is available from the context menu (the “trash” icon next to the item). For a page there is also an “Open” option that takes you to editing the content of that page in the Application.

Tip: The progress (steps) bar displayed to the user can be hidden if needed – this is done with the Steps bar visibility in the Properties.

Step properties

Each step has a set of basic properties defining its role in the form. In Eximee Designer they are visible both in the Stepstab and in the Sourcetab. In the Steps tab these properties are available as text fields that can be filled according to the hints shown in those fields. In the Source tab the same properties appear under their technical identifiers:

• id – unique identifier of the step (internal technical name). By default steps receive an ID in the form Step1, Step2 etc. Its editing is available only from the Source.

• titleKey – translation key of the step title. By default it takes the value StepX.title (where X is the step ID). Setting or editing the appropriate title is possible in the Steps tab where you can quickly add or edit the title for the main language of the application or in the Translations tab after searching for the step of interest where you can add or edit the title for different languages included in the application.

• visibleCondition – the visibility condition of the step, written as a logical expression. If the condition is not met, that step will be automatically skipped during the presentation of the application to the user. In the condition you can refer to field values or session variables (syntax details see the Expression Language in the documentation). The condition can also be configured in the Steps – tab in the “Add condition” field for the appropriate step. For example, to make a step visible only when the user checked the checkbox with ID GesCheckbox1, the condition may look like this:

// Step visibility condition (example)
getValue("GesCheckbox1") == "true"

This condition will return "true" when checkbox1 is checked, which will cause the step in which the condition was used to appear.

Remember that the id of the step is a unique value and it is best not to change it after creating steps (it is linked, for example, to translation keys and logic). However, title and visibility condition can be modified at any time – these changes affect the behavior and appearance of the form during filling.

Page properties

Each form page has an extensive set of properties, divided in the editor into thematic sections: Basic properties, Layout, Data quality, Interactions, Styling, WCAG and Other. To edit the properties of a specific page, open that page in edit mode in the Application tab (e.g., by clicking the page name in the Steps tab list or selecting the “Open” option) and then click on the empty page background – the page properties will appear in the right panel. Note: some basic properties (identifier, title, visibility condition) can also be changed from the list in the Stepstab, however most settings are available only in page edit mode.

Below is a summary of key page properties by section:

Basic page properties

• Id – unique page identifier. The Id automatically takes the next value PageX (where X corresponds to the page number) when creating a new page and it cannot be changed in the graphical editor – it is only possible in the Source. Id must be unique within the form and is visible in the url during form filling.

• Business identifier (mid) – an optional “friendly” page identifier. By default mid is the same as Id of the page but you can give your own business name. It is also editable in the Steps tab by clicking the first column in the page row. Mid pshould be unique.

• Title – the page title displayed to the user (e.g., Summary). You can enter static text, leave it empty or fill it in the Translations tab if the page should have a title in different languages.

• Title (key) – the translation key of the page title. It works similarly to the step titleKey – it allows defining the title in different languages (the default value is e.g. PageX.title where X is the page number). In the Translations tab you can add the appropriate entries for this key.

• Page number – ordinal number indicating which numbered page of the application the screen is. This is a read-only field (the system numbers pages itself in the order they appear in the structure).

• Label of the "Next/Submit" button – allows defining custom text for the navigation button to go to the next page or submit the application, visible on that page (e.g., “See summary” instead of “Next”). By default the button label isNextorSubmit requeston the last page.

• Label of the "Next/Submit" button (key) – translation key for the button label. It is automatically filled by the form with the value PageX.nextButtonLabel (where X is the page number). If the form is multilingual, the appropriate values should be added in the Translations tab. Label display hierarchy for the button: if no custom button label is defined for the page, the field uses the label provided from session variables / nextButtonTextsubmitButtonText, and then global platform keys are used ( / iew.navigation.next).

Layout

• Number of columns iew.navigation.submit – the field shows the number of columns defined for the form. The field is not editable from the Application Source tab. Changing in the

Data quality

• Visibility condition tab was described in falsePage visibility formula (expression) that determines whether the page should be shown to the user. If the condition returns , the page will be skipped during application display (the user will not see it). Conditions are written as JavaScript expressions – we can use functions such as getValue("componentId") (to get the value of the component with the given identifier) or isVisible("componentId") (to check a component's visibility). More examples are described in Expression language for defining conditions (conditions with getValue)

The condition editor suggests available syntaxes, field identifiers and variable names. A sample condition for a page that should appear only if a select field has a specific value:
// Page visible only when the "type" field has value "A"

• Validators getValue("typWniosku") == "A" – a field that allows attaching additional validation rules checking the correctness of data entered on the page. Adding validators is done by attaching an appropriate script validator – more information can be found in the

Interactions

• Listening Custom complex validations – mechanism responsible for dynamic refreshing Listeningof the page/component/variable state in response to changes in listened elements. This means that if, for example, a page visibility condition refers to the value of another component, that component should be added to the attribute. This way a change of that component's value will trigger recalculation/refresh of the condition and possibly show/hide the page. In the Listening attribute you can specify many components. Editing is done through a list window – after clicking the List Id button, a popup appears with a list of available components. They can be searched by providing both midand field . The popup also shows components already selected - you cannot select the same one twice. Visibility condition if the page has dependent on the fieldumowaCheckbox dependent on the field , you should add to the Listening

Styling

• Style name of that page. We proceed similarly for step conditions – because a step does not have its own listening attribute, components that determine its visibility are added to the listening of the first page of the step. – list of CSS styles assigned to the page. Enables giving the page (and all its elements) an individual appearance via styling in a CSS stylesheet. The value entered in this field will be added as an HTML class to the page container. You can enter multiple classes separated by spaces here. (More information is available in the documentation in the.)

• Form and component styles Sticky next button (customPositionedNavbarCondition) true– condition for a specific behavior of the navigation “Next”/“Submit” button. This function is used mainly in native mobile apps – it allows, for example, to make the button always visible at the bottom of the screen (pinned) if a given condition is met. After setting the condition to _{, the navigation button display mode will change for that page.}

• (Availability of this feature depends on the license and may not be available in all deployments) Hide cancel button ("X") _{, the navigation button display mode will change for that page.}

• – a flag specifying whether the cancel button (marked with an X, usually in the form header) should be visible on the page. By default in the mobile channel such a button is displayed allowing interruption of the application. Checking this option will hide it on that page. Hide back button _{, the navigation button display mode will change for that page.}

• – a flag controlling the visibility of the back navigation button (with an arrow) in the mobile app. In some mobile templates a “back” arrow to the previous screen is displayed next to the form title – enabling this flag will remove that element on the given page. Hide application title _{, the navigation button display mode will change for that page.}

WCAG

• – a flag deciding whether to show the whole application title at the top of the screen. In typical web deployments the form title is displayed, for example, in the header. If the form has its own graphic title or you simply want to save space, you can hide the default title by checking this option. Page contains a form – a flag indicating whether the page should be treated by assistive technology as a standalone form. Enabling this option will add the attributerole="form" to the page container, which is sometimes required to meet WCAG accessibility standards (especially when there are multiple independent forms within a single application). Details about this property are described in theWCAG – page as a form

Other

• . Enabling this option is usually not necessary for ordinary application pages (which are anyway inside the main form of the whole application), but it may be useful in atypical scenarios. Curtain – a configurable message displayed at the top of the page as a curtain. It allows, for example, blocking interaction with the rest of the form until the user performs some action or simply displaying a highlighted announcement. Curtains can serve as informational banners. This property allows selecting a previously defined Text Content (TextContent) _{, the navigation button display mode will change for that page.}

• as the message or entering a textual message. Bottom bar

  • – an additional bar at the bottom of the page (mobile apps only) used to present, for example, an expandable section with additional information or actions. Several properties are available to configure this bar: Should the text be expandable? (expandable) – indicates whether the bottom bar should contain expandable content

  • (i.e., initially collapsed message with an option to “expand”). By default the option is enabled (the bar is expandable). If unchecked, the bar will be fixed (non-collapsible). Alternative appearance (mode)

  • – enables an alternative presentation mode of the bar. Depending on the implementation this may mean different coloring or style of the bar. Expand button text key (showToggleTextKey) – translation key for the link/button text that expands the bar. By default it may be e.g. “Read more”. If you enter e.g.bottom.expand , you should add the corresponding entry in translations (e.g.bottom.expand = "Show more information" ). The Collapse button text key (hideToggleTextKey)

  • works analogously – a key for the text of the collapse option (e.g., “Hide details”). Bar visibility condition (visibleCondition)

  • – a logical condition determining whether to show the bottom bar on a given page at all. For example, if the bar should be visible only for new customers, you can enter the appropriate condition here. Expanded content (topTextContentName) Content (TextContent)– the name of the artifact Content whose content will be displayed after expanding the bottom bar. This allows the designer to create rich HTML (e.g., a list, a table, links) in a

  • component and embed it in the bar. Collapsed content (bottomTextContentName) – similarly, the name of the artifact containing the content that is visible before expanding the bar (i.e., a short message on the bar). After clicking “expand” this message can be replaced or extended by the.

  _{, the navigation button display mode will change for that page.}

• topTextContent Login required condition (loginRequiredCondition) – a condition specifying the need for the user to log in before the page is displayed. If a condition is defined here (e.g.getValue("czyKlientZalogowany") != "true"

), then if it is met the system will force user authentication (login) before the page is shown. This functionality is used in scenarios where part of the application is available only to logged-in users. fixedColumns/Additionally, there are some page properties available only via XML editing (Source tab). These include, among others, inheritLayout – related to inheriting column layout from an older engine version – whether migratedLayoutOn

(layout migration flag). In most cases there is no need to modify them manually.

Good design practices

• When designing the steps and pages structure, consider several good practices that will make the application easier to maintain and ensure correct logic operation: Thoughtful naming: Id and mid Artifact names (forms, components, variables) should be consistent and understandable. Decide whether you use Polish or English and stick to the convention. Page1 for pages it is best to give names that reflect their content or role. Avoid leaving default names like – better replace them with e.g. or SummaryAddressData

• . This way you'll more easily find your way in the structure and business identifiers appearing, for example, in conditions will be more readable. Unique identifiers: mid Every step, page and component should have a unique mid (business identifier). The system enforces uniqueness within a single form, but if you duplicate artifacts or copy form fragments it is easy to overlook duplicated identifiers. Duplicates mid can lead to incorrect behavior of conditions or listening. When duplicating elements always check and change

• to a unique one. Similarly translation keys – do not use the same key for two different texts. Readability and modularity of conditions: When creating complex conditional expressions, care about their readability. Use parentheses and naming conventions to clearly express the intention (e.g. getValue("netIncome") > 0 && getValue("fullTime") == "true" instead of an unreadable chain). Avoid repeating the same logic in many conditions – if several fields or pages use the same expression consider extracting it to a single session variable or to a technical field. For example, you can add a technical field mid named czyKlientVIP with a default expression evaluating the customer's data, and then in conditions of various steps refer only togetValue("czyKlientVIP") . Such centralization of expressions will simplify future changes (you modify the formula in one place) and reduce the risk of errors. In Eximee you can mark a as text field as a technical field by checking the appropriate option in the Properties Securitysection of the text field - in the

• . Such a field is invisible to the user but available to the logic – useful for storing auxiliary values. Testing visibility logic: After configuring conditions and listening always test different filling scenarios of the application. Make sure that steps and pages appear and disappear as expected in response to user data. Test combinations of answers – especially edge cases – to avoid situations where, for example, a certain navigation path accidentally skips an important page. Remember the case when a condition refers to a field with a default value: if the controlling field is hidden but has a default value that satisfies the condition, the dependent page/component. Examplewill still be displayed : a radio field has the first option “YES” selected by default and we conditionally show another field when it is “YES” – even when the radio is hidden, the default value "YES"

• still causes the dependent field to be revealed. Such situations should be handled consciously, e.g., set no default answer for the radio. Order and consistency:

• Keep the structure tidy – do not create unnecessary empty steps, do not place single fields on separate pages unless necessary (it is better to group them thematically within one page so the user doesn’t have to click “Next” for every small piece of information). Also try to ensure each step logically corresponds to one topic of the process – this will help both the user understand the progress and you to expand the application if needed. Translation naming: StepX.title and PageX.title . In the tab of the Translations If the form is bilingual, ensure consistent naming of translation keys for steps and pages. Conventionally the pattern

• is used so you can easily review all keys – avoid duplicates or unnecessarily similar entries. Reusing components: composite component If a certain set of fields appears in many places, consider creating a

• instead of duplicating those fields manually everywhere. This will make changes easier and maintain consistency. Parking the application:

If your business process allows parking (saving a draft) before submission, make sure the form handles it correctly. By default Eximee allows the user to park the application with the “Save and return later” button (if the deployment provides it). However, this does not apply to steps after the save point – parking the application is not possible there, so you do not need to do anything extra.

Debugging steps and pages – checklist

1. Despite efforts, complicated applications may have navigation or visibility logic issues. Here is a checklist to help find the most common errors:

   • Step/page does not appear at all: false).

   • Check the visibility condition of the step and all parent elements. Maybe the condition is always false (e.g., a typo in the field name in the expression causes it to always return

   • Make sure that the identifiers used in the Visibility condition exist and are correct.

2. Check whether the given step was placed as an element of another step. Eximee does not support nested steps — each step must be at the top level of the structure.

   Visibility condition does not work dynamically: to theIf the condition is based on a field changed by the user, and the page/step does not appear or disappear during interaction, almost certainly the Listening is missing. Check whether the dependent component has the

3. listening configured for that field. If missing, add the missing links and test again. An element is displayed although it should not: == instead of !=A typical cause is a condition referring to a field with a default value, as mentioned above. If the dependency is more complex, also check whether you did not confuse operators (e.g., using

4. ) or data types (are you comparing text to a number?). When debugging conditions it may help to temporarily add a text field to the form and set its text to the result of the problematic expression – you will then see “live” what the expression returns. Problems with navigation between steps: If the “Next” button does not respond or the user is stuck, make sure there is at least one visible

5. page in the step. It may happen that all pages in the step were hidden by conditions – then after completing the previous step the system may have nowhere to go. Solution: either ensure at least one page always appears, or conditionally skip the entire step (put the condition on the step instead of on each page separately). Cannot edit the form (edit icon is greyed out): Probably the form is locked by the draft mechanism – e.g., another user edited it and did not save. You can release the lock as described in theDraft – draft/work copy

6. section. In Eximee Designer's form list view a locked artifact shows appropriate information and an option to take over the draft. Checking process associations:

7. When using EximeeRouter2, verify in the Save Point configuration the process name and the business key mapping. An incorrect process name may cause nothing to happen after submission (the application will be saved but the process will not start). In system logs look for messages related to process start. Logs and developer mode: Source In case of hard-to-diagnose problems use the browser logs (JS console) and Eximee server logs. Verify in the

8. tab whether the step and page properties there match expectations (this will help catch, for example, accidentally overwritten identifiers or missing entries). Use the FAQ: If in doubt consult the Eximee Designer FAQ

document – many common problems are described there along with solutions. For example, it explains why a dependent component may appear despite the control being hidden (default value), or what to do when changes in a composite component are not visible in the application. true/false Applying the above checklist should help quickly identify most errors related to the steps and pages mechanism. If the problem is unusual, it is worth analyzing it step by step, simplifying conditions (e.g., temporarily set them to

to isolate the influence of other factors) and adding diagnostic elements (technical fields, text fields, etc.).

Relations to other documentation sections

• The “Steps and pages” mechanism is closely related to other aspects of building an application in Eximee. For full understanding and correct configuration it is worth also reading the following documentation topics: Processes and EximeeRouter2 Processes– if the form is part of a larger business process, read the document. It describes how to define and run processes in Eximee BPMS and how Eximee Designer communicates with EximeeRouter2 when submitting an application. Understanding this integration will help better use save actions in the Save Point

• Translations (e.g., passing process variables, handling exceptions). Translations – the titleKey or tab in the editor allows adding translations of texts used in the form (including page titles, button labels, etc.). Remember that keys such as labelForNextOrSubmitButtonKey

• require adding corresponding entries here, otherwise the user will not see the desired content. Styling and UX – the steps mechanism affects the user experience, so it is worth learning the possibilities of form styling in the documentation. There you will find information on how to globally adjust the appearance of the steps bar, navigation buttons, or page layout. For example, there are platform styles and the ability to add custom CSS stylesheets to the application. Relevant sections (e.g.Component styling

• ) show examples of using style properties. WCAG – accessibility WCAG– if the project requires WCAG compliance, be sure to read the dedicated documentation. It contains guidelines on building accessible forms, descriptions of functions such asariaLabel/Description , accessibility audit in the editor and tips for creating components friendly to screen readers. In the context of steps and pages, make sure for example that each step is announced logically (if the steps bar is hidden, consider adding hidden headings on pages informing about the stage). The role=form

flag mentioned earlier also relates to WCAG recommendations.