Form steps and pages

Steps and pages are the basic elements of a form structure in Eximee Designer that allow organizing multi-step forms. The step groups one or more pages and represents a logical stage of the form (e.g., the stage of collecting company co-owner data, the borrower's income data, or an 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 within 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 tab.

“Steps” tab — editing the form structure

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

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

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

• 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 on the item). For a page there is additionally an “Open” option that takes you to edit the content of that page in the Application.

Tip: The progress (steps) bar shown to the user can be hidden if needed — use the Steps bar visibility in the tab 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 The number of page columns can be changed after creating the form by editing its definition. In the application edit mode go to thetab. In the Steps tab these properties are available as text fields that can be filled in according to the hints shown in those fields. In the The number of page columns can be changed after creating the form by editing its definition. In the application edit mode go to the tab the same properties appear under their technical identifiers:

• id – the unique identifier of the step (internal technical name). Steps by default receive an ID in the form Step1, Step2 etc. Its editing is available only from the The number of page columns can be changed after creating the form by editing its definition. In the application edit mode go to the.

• titleKey – the translation key for 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 the different languages included in the application.

• visibleCondition – the visibility condition of the step, written as a logical expression. If the condition is not met, the given step will be automatically skipped when presenting the application to the user. In the condition you can refer to field values or session variables (see the documentation section for syntax details: Expression language ). 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 has checked a 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 where the condition was used to appear.

Remember that the id of a step is a unique value and it's 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 background of the page — 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 when editing the page.

Below is a summary of key page properties by section:

Basic page properties

• Id – the unique identifier of the page. The Id automatically takes the next value PageX (where X corresponds to the page number) when creating a new page and cannot be changed in the graphical editor — it is only possible in the The number of page columns can be changed after creating the form by editing its definition. In the application edit mode go to the. Id tab. It must be unique within the form and is visible in the URL during application 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 should be unique.– the page title displayed to the user (e.g., Summary). You can enter static text, leave it empty or fill it in the

• Title tab if the page should have a title in different languages. Translations Title (key)

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

• – the ordinal number indicating which page in the application the screen is. This is a read-only field (the system numbers pages automatically in the order they appear in the structure). Next/Submit button label

• – allows defining a custom text for the navigation button that moves to the next page or submits the application, visible on the given page (e.g., “See summary” instead of “Next”). By default the button label is “ ” or “ContinueSubmit” on the last page. applicationNext/Submit button label (key)

• – the 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, you should add the appropriate values in the Translations tab. Hierarchy of button label display: if a page does not have its own button label defined, the field uses the label provided from session variables nextButtonText submitButtonText / , and next the global platform keys are used (– the field shows the number of columns defined for the given form. The field is not editable from theiew.navigation.next / iew.navigation.submit).

Layout

• Number of columns Application tab. Changing in the tab was described in The number of page columns can be changed after creating the form by editing its definition. In the application edit mode go to the Page editing – a formula (expression) that determines whether the page should be shown to the user. If the condition returns

Data quality

• Visibility condition , the page will be skipped during form display (the user will not see it). Conditions are written as JavaScript expressions — we can use functions such as falsegetValue("componentId") (to get the value of a component with the given identifier) or isVisible("componentId") (to check visibility of a component). 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 field "typ" has value "A"

getValue("applicationType") == "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

• Validators Custom complex validations section.

Interactions

• Listening – the mechanism responsible for dynamic refreshing of 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, you should add that component to the Listeningattribute. This way a change in the value of that component will trigger recalculation/refresh of the condition and possibly show/hide the page. In the Listening attribute you can indicate many components. Editing is done via a list window – after clicking the List button, a popup with the list of available components appears. You can search them by both Id and mid. The popup also shows components already selected - you cannot pick the same one twice. field is sufficient. if the page has Visibility condition dependent on the field umowaCheckbox, you should add umowaCheckbox to the Listening of that page. We proceed analogously for step conditions – because a step has no own listening attribute, components that determine its visibility are added to the listening of the first page of the step.

Styling

• Style name – a list of CSS styles assigned to the page. It allows giving the page (and all its elements) an individual appearance by 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. (More information is in the documentation in the Form and component styles.)

• section). Sticky next button (customPositionedNavbarCondition) true– a condition for specific behavior of the navigation “Next”/“Submit” button. This function is mainly used in native mobile apps — it allows, for example, making 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 for that page will change its display behavior.}

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

• – a flag that determines 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 the user to abort the application. Enabling this option will hide it on the given page. Hide back button _{, the navigation button for that page will change its display behavior.}

• – 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 for that page will change its display behavior.}

WCAG

• – a flag deciding whether to show the overall 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 enabling this option. Page contains a form – a flag that determines whether the page should be treated by assistive technology as a standalone form. Enabling this option will add the attributerole="form" , which may be required to meet WCAG accessibility standards (especially when multiple independent forms appear within one application). Details about this property are described in theWCAG – page as form

Other

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

• as the message or entering a text 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. There are several properties configuring 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 you uncheck it, the bar will be fixed (non-collapsible). Alternative appearance (mode)

  • – enables an alternative way of presenting the bar. Depending on deployment this may mean different colors or bar styling. Expand button text key (showToggleTextKey) – the translation key for the link/button text that expands the bar. By default this might be e.g. “Read more”. Entering here e.g.bottom.expand , you should add the corresponding translation entry (e.g.bottom.expand = "Show more information" ). The same applies to Collapse button text key (hideToggleTextKey)

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

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

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

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

• topTextContent Login required condition (loginRequiredCondition) – a condition specifying the necessity of user login before displaying the page. If a condition is defined here (e.g.getValue("isUserLoggedIn") != "true"

), then when it is met the system will require 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 through 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.

Design best practices

• When designing the structure of steps and pages it is worth following several good practices that will facilitate maintaining the application and ensure correct logic operation: Thoughtful naming: Id and mid Artifacts 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's best to give names that reflect their content or role. Avoid leaving default names like – it's better to replace them with, for example, or SummaryAddressData

• . This way you'll more easily find your way in the structure, and business identifiers used in conditions will be more readable. Unique identifiers: mid Each 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's 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 for translation keys – do not use one 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 convey intent (e.g. getValue("netIncome") > 0 && getValue("employment") == "true" instead of an unreadable string). Avoid repeating the same logic in many conditions – if several fields or pages use the same expression, consider extracting it into a single session variable or a technical field. For example, you can add a technical field mid named isVIPCustomer with a default expression evaluating the customer data, and then in conditions of various steps refer only togetValue("isVIPCustomer") . 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 selecting the appropriate option in the Properties Securitysection of the text field. Such a field is invisible to the user but available for 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 intended in response to user data. Test combinations of answers — especially edge cases — to avoid situations where, for example, a certain navigation path inadvertently 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 will still be displayed. Example: 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., by setting no default answer for the radio.

• Order and consistency: Keep structure tidy – do not create unnecessary, empty steps, do not place single fields on separate pages unless necessary (it's better to group them thematically on one page so the user doesn't have to click “Next” for every minor piece of information). Also try to have each step correspond logically to one process topic — this will help the user understand progress and make it easier for you to expand the application later.

• Translation naming: If the form is bilingual, ensure consistent naming of translation keys for steps and pages. The usual pattern is StepX.title and where X is the page number). In the . In the tab of the Translations so you can easily review all keys — avoid duplicates or unnecessarily similar entries.

• Reusing components: If a certain set of fields appears in many places, consider creating a composite component instead of duplicating these fields manually in each place. This will make changes easier and maintain consistency.

• Parking the application: If your business process allows parking (saving a draft) before submission, ensure the form handles this correctly. By default Eximee allows the user to park the application using 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 there is not possible, so you do not need to do anything extra.

Debugging steps and pages – checklist

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

1. A step/page does not appear at all:

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

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

   • Check whether the 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.

2. Visibility condition does not work dynamically:

   If the condition is based on a field changed by the user, and the page/step does not appear or disappear during interaction, almost certainly there is missing Listening. Check whether the dependent component has the Listening listening added for that field. If missing, add the missing links and test again.

3. An element is displayed although it should not be: 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 mixed up operators (e.g., using == instead of !=) or data types (are you comparing text with a number?). When debugging conditions it can be helpful to temporarily add a text field to the form and set its text to the result of the problematic expression — you will see “live” what the expression returns.

4. 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 page in the given step. It may happen that all pages in the step have been hidden by conditions — then after finishing the previous step the system may have nowhere to go. Solution: either ensure that at least one page always appears, or conditionally skip the whole step (a condition on the step instead of on each page separately).

5. Cannot edit the form (edit icon greyed out): The form was probably locked by the draft mechanism — e.g., another user edited it and did not save. You can release the lock as described in the Draft – draft/work copysection. In Eximee Designer's forms list view a locked artifact shows relevant information and an option to take over the draft.

6. Checking process associations: 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 saves but the process does not start). Look in the system logs for messages about process start.

7. Logs and developer mode: In case of hard-to-diagnose problems use the browser logs (JS console) and Eximee server logs. Verify in the The number of page columns can be changed after creating the form by editing its definition. In the application edit mode go to the tab whether step and page properties there match expectations (this will catch, for example, accidentally overwritten identifiers or missing entries).

8. Use the FAQ: If in doubt, check the Eximee Designer FAQ document — many common problems are described there with solutions. For example, it explains why a dependent component may show despite the controller being hidden (default value), or what to do when changes in a composite component are not visible in the application.

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 true/false to isolate the influence of other factors) and adding diagnostic elements (technical fields, text fields, etc.).

Connections to other documentation sections

The “Steps and pages” mechanism is closely related to other aspects of creating an application in Eximee. For full understanding and correct configuration it is worth also reading the following documentation topics:

• Processes and EximeeRouter2 – if the form is part of a larger business process, read the Processesdocument. It describes how to define and start 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 (e.g., passing process variables, handling exceptions).

• Translations – the Translations tab in the editor allows adding translations of texts used in the form (including page titles, button labels, etc.). Remember that keys such as titleKey or labelForNextOrSubmitButtonKey require adding corresponding entries there, 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 styling the form. The styles documentation contains 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 option to add custom CSS stylesheets to the application. Relevant sections (e.g. Component styling) show examples of using style properties.

• WCAG – accessibility – if the project requires WCAG compliance, be sure to read the dedicated WCAGdocumentation. It contains guidelines for building accessible forms, descriptions of functions such as ariaLabel/Description, accessibility auditing in the editor and tips for creating components friendly to screen readers. In the context of steps and pages, ensure for example that each step is announced logically (if the steps bar is hidden, consider adding hidden headings on pages indicating the stage). The role=form flag mentioned earlier also relates to WCAG recommendations.

In conclusion, the “Steps and pages” mechanism forms the skeleton of every application in Eximee Designer — mastering its rules will allow you to build elaborate yet clear forms. Use the documentation and the above tips while working, and your applications will correctly navigate the user from the first step to the thank-you page in a user-friendly way and in line with business requirements.