> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/kroki-i-strony-formularza.md).
# Form steps and pages
**Steps** and **pages** are the basic structural elements of a form in Eximee Designer that let you organize multi-step forms. **A step** groups one or more pages and represents a logical stage of the form (e.g. the stage of collecting data from company co-owners, the borrower’s income data, or the application summary), and **a page** is a single screen/subpage containing specific fields and components. In this way, the designer defines the user’s navigation path – determines the order of steps, the pages within them, and the conditions for displaying them. In the user interface, steps can be indicated with a progress bar (the so-called step bar) – its visibility is configured in the **Properties.**
Figure 1. Example view of the step bar on an application.
## "Steps" tab – editing the form structure
We manage the structure of steps and pages in the **Steps** application editor tab. After opening the form, this tab is displayed by default in preview mode (read-only). There you can see a list of all steps and the pages belonging to them – for each element the **business identifier (mid)**, **title** (if provided) and **visibility condition** (a conditional expression that determines whether a given step/page should be displayed).
{% hint style="warning" %}
*Note:* these conditions are not executed in this view, only displayed for information.
{% endhint %}
To edit the structure, switch the **Steps** tab to edit mode (pencil icon – **Edit process**") – it may be necessary to first release any working lock (draft) of the form. In edit mode you can add and delete steps and pages, edit their basic properties, and change the order using *drag & drop.* Keep a few rules in mind:
* **You cannot delete all steps!** – at least one step must remain in the form.
* **Adding a new step** automatically creates a new page inside that step (a step cannot be empty).
* **Deleting a step** deletes 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 (trash icon next to the element). For a page, there is also an "Open" option, which takes you to editing the content of that page in the **Application**.
> **Tip:** The progress bar (step bar) shown to the user can be hidden if needed – use the *Step bar visibility* option 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 **Steps**tab and in the [**Source**](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/podglad-definicji-formularza-xml.md).\
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 **Source** the same properties appear under their technical identifiers:
* id – the unique identifier of the step (internal technical name). By default, steps receive IDs in the form of `Step1`, `Step2` etc. It can only be edited from the [**Source**](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/podglad-definicji-formularza-xml.md).
* **titleKey** – 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** 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 we are interested in, where you can add or edit titles for different languages included in the application.
* **visibleCondition** – visibility condition for the step, written as a logical expression. If the condition is **not met**, the step will be **automatically skipped** when the application is presented to the user. In the condition you can refer to field values or session variables (syntax details see chapter [*Expression language*](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/jezyk-wyrazen.md) in the documentation). The condition can also be configured in the **Steps –** in the "Add condition" field for the relevant 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:
```javascript
// Step visibility condition (example)
getValue("GesCheckbox1") == "true"
```
This condition will return "true" if Checkbox1 is checked, which will cause the step in which the condition was used to appear.
{% hint style="warning" %}
Note!
Defining a visibility condition for a step does not automatically update the step bar. For the step visibility to refresh dynamically, for all pages within that step you need to:
* set the same visibility condition,
* add listening to the components used in the condition (tab **Application** → Page properties → section **Interactions)**.
{% endhint %}
Remember that the step ID is unique and it is best not to change it after the steps have been created (it is linked, for example, to translation keys and logic). However, *title* and *visibility condition* it can be modified at any time – these changes affect the behavior and appearance of the form while it is being filled out.
## 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 **Steps**tab, but most settings are available only in page editing.
Below is a summary of the key page properties by section:
#### Basic page properties
* **Id** – the unique page identifier. The Id automatically takes the next value `PageX` (where X corresponds to the page number) when a new page is created and cannot be changed in the graphical editor – this is only possible in the **Source**. **Id** must be unique within the form and is visible in the URL address while filling out the application.
* **Business identifier (mid)** – optional "friendly" page identifier. By default **mid** is the same as the **Id** page, but you can assign your own business name. It can also be edited in the **Steps,** by clicking the first column in the page row. **Mid p**should be unique.
* **Title** – the page title shown to the user (e.g. Summary). You can enter static text, leave it blank, or fill it in the **Translations** if the page is to have titles in different languages.
* **Title (key)** – translation key for the page title. It works similarly to the *titleKey* step – it lets you define 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** – the ordinal number indicating which page of the application this 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 you to define a custom text for the navigation button that moves to the next page or submits the application, visible on a given page (e.g. "See summary" instead of "Next"). By default, the button has the label "**Next**" or "**Submit** **application**" on the last page.
* **"Next/Submit" button label (key)** – translation key for the button label. It is automatically filled in by the form with the value `PageX.nextButtonLabel` (where X is the page number). If the form is multilingual, appropriate values should be added in the **Translations.**\
\&#xNAN;*Button label display hierarchy:* if no custom button label has been defined for the page, the field uses the label provided from the session variables `nextButtonText` / `submitButtonText`, and then the global platform keys are used (`iew.navigation.next` / `iew.navigation.submit`).
#### Layout
* **Number of columns** – this field shows the number of columns defined for the given form. The field is not editable from the **Application** The change in the **Source** was described in [Page editing](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/edycja-stron.md)
#### Data quality
* **Visibility condition** – a formula (expression) that determines whether the page should be shown to the user. If the condition returns `false`, the page will be skipped when the application is displayed (the user will not see it). Conditions are written as JavaScript expressions – you can use functions such as `getValue("idKomponentu")` (retrieving the value of the component with the given identifier) or `isVisible("idKomponentu")` (checking the visibility of a component). More examples are described in [Expression language for defining conditions (conditions with getValue)](/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/jezyk-wyrazen-definiowania-warunkow-warunki-z-getvalue.md)\
The condition editor suggests available syntax, field identifiers, and variable names. Example condition for a page that should appear only if a choice field has a specific value:
```javascript
// Page visible only when the value "A" is selected in the "typWniosku" field
getValue("typWniosku") == "A"
```
* **Validators** – a field that lets you attach additional rules checking the correctness of data entered on the page. Validators are added by attaching the appropriate script validator – more information can be found in the section [Complex (custom) validations](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/walidacja-wartosci-komponentow/walidacje-zlozone-wlasne.md)
#### Interactions
* **Listening** – a mechanism responsible for **dynamic refreshing** the state of a page/component/variable in response to changes in the 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 **Listening**. Thanks to this, a change in the value of that component will cause the condition to be recalculated/refreshed and potentially show/hide the page. In the **Listening** attribute, you can specify multiple components.\
Editing is done through the list window – after clicking the **List,** a popup appears with a list of available components. You can search for them by entering both **Id** and **mid**. The popup also shows components already selected - you cannot select the same one twice.\
\&#xNAN;*Example:* if the page is **Visibility condition** dependent on the field `umowaCheckbox`, you need to add `umowaCheckbox` to the **Listening** of this page. We do the same for step conditions – because a step does not have its own listening attribute, the components that determine its visibility are added to the listening of the first page of the step.
#### Styling
* **Style name** – the list of CSS styles assigned to the page. It lets you give the page (and all its elements) an individual look through styling in the CSS stylesheet. The value entered in this field will be added as an HTML class to the page container. You can enter multiple classes here separated by spaces. *(More information can be found in the documentation in the section* [Form styles and component styles](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze.md)*.)*
* **Sticky next button (customPositionedNavbarCondition)** – a condition for the specific behavior of the "Next"/"Submit" navigation button. This is a function mainly used in native mobile applications – it lets you, for example, make the button always visible at the bottom of the screen (pinned) if a given condition is met. When the condition is set to *true*, for the given page the navigation button changes the way it is displayed.\ *(Availability of the functionality depends on the license and may not be available in all deployments)*
* **Hide the cancel button ("X")** – a flag that determines whether the cancel button should be visible on the page (marked with an X, usually in the form header). By default, in the mobile channel, such a button is displayed, allowing the application to be interrupted. Selecting this option will hide it on the given page.\ *(Availability of the functionality depends on the license and may not be available in all deployments)*
* **Hide the back button** – a flag controlling the visibility of the back navigation button (with an arrow) in the mobile application. 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.\ *(Availability of the functionality depends on the license and may not be available in all deployments)*
* **Hide application title** – a flag determining whether the title of the entire application should be shown 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 graphical title or if we simply want to save space, we can hide the default title by selecting this option.\ *(Availability of the functionality depends on the license and may not be available in all deployments)*
#### WCAG
* **Page contains a form** – a flag determining whether the page should be treated by assistive technology as a standalone form. Setting this option adds the `role="form"`attribute to the page container, which may be required to meet WCAG accessibility standards (especially when there are many independent forms within a single application). Details of this property are described in the section [*WCAG – page as a form*](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-strona-jako-formularz.md). Enabling this option is usually not necessary for ordinary application pages (which are already inside the main form of the entire application), but it may be useful in unusual scenarios.
#### Other
* **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 you to choose a predefined **Content (TextContent)** as the message or enter a text message.\ *(Availability of the functionality depends on the license and may not be available in all deployments)*
* **Bottom bar** – an additional bar at the bottom of the page (mobile applications only) used to present, for example, an expandable section with additional information or actions. There are several properties available for configuring this bar:
* *Should text expand? (expandable)* – whether the bottom bar should contain **expandable content** (that is, an initially collapsed message with an "expand" option). By default, this option is enabled (the bar is expandable). If we uncheck it, the bar will be fixed (not collapsible).
* *Alternative appearance (mode)* – enables an alternative way of displaying the bar. Depending on the implementation, this may mean a different color scheme or bar style.
* *Expand button text (showToggleTextKey)* – translation key for the text of the link/button that expands the bar. By default, this may be something like "Read more". If you enter e.g. `bottom.expand`, you need to add the appropriate translation entry (e.g. *bottom.expand = "Show more information"*). Similarly, *Collapse button text (hideToggleTextKey)* – the key for the text of the option to collapse the bar (e.g. "Hide details").
* *Bar visibility condition (visibleCondition)* – a logical condition determining whether to show the bottom bar on the given page at all. For example, if the bar should be visible only for new customers, you can enter an appropriate condition here.
* *Expanded content (topTextContentName)* – the name of the artifact **Content (TextContent)**, whose content will be displayed after the bottom bar is expanded. This allows the designer to create rich HTML (e.g. a list, table, links) in the **Content** component and embed it in the bar.
* *Collapsed content (bottomTextContentName)* – similarly, the name of the Content artifact with content that is visible **before expanding** the bar (that is, a short message on the bar). After clicking "expand", this message can be replaced or extended with the content *topTextContent*.
*(Availability of the functionality depends on the license and may not be available in all deployments)*
* **Login required condition (loginRequiredCondition)** – a condition determining 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 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.
*Additionally, there are some page properties available only through XML editing (Source tab). These include, among others, `fixedColumns`/`inheritLayout` – related to inheriting the column layout from the old version of the engine – whether `migratedLayoutOn` (layout migration marker). In most cases there is no need to modify them manually.*
## Good design practices
When designing the structure of steps and pages, it is worth following a few good practices that will make the application easier to maintain and ensure the correct operation of the logic:
* **Thoughtful naming:** Artifact names (forms, components, variables) should be consistent and understandable. Decide whether you use Polish or English and stick to the convention. **Id** and **mid** for pages, it is best to name them in a way that reflects their content or role. Avoid leaving default names such as *Page1* – it is better to replace them with e.g. *AddressData* or *Summary*. This way it will be easier to find your way around the structure, and the business identifiers appearing e.g. in conditions will be more readable.
* **Unique identifiers:** Every step, page and component should have a unique **mid** (business identifier). The system does enforce uniqueness within a single form, but if you duplicate artifacts or copy form fragments, it is easy to overlook repeated identifiers. Duplicate **mid** can lead to incorrect behavior of conditions or listening. When duplicating elements, always check and change **mid** 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, make sure they are readable. Use parentheses and naming conventions to clearly express the intent (e.g. `getValue("dochódNetto") > 0 && getValue("etat") == "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 into a single session variable or technical field. For example, you can add a **technical field** with **mid** `czyKlientVIP` using a default expression evaluating the customer’s data, and then in the conditions of different steps refer only to `getValue("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 **text field** as a **technical field,** by selecting the appropriate option in **the Properties** of the text field – in the **Security**section. Such a field is invisible to the user, but available to logic – useful for storing helper values.
* **Testing visibility logic:** After configuring conditions and listening, always **test different scenarios** of filling out the application. Make sure that steps and pages appear and disappear as intended in response to user input. Test answer combinations – especially edge cases – to avoid situations where, for example, a certain navigation path accidentally skips an important page. Remember the case where a condition refers to a field with a default value: if the controlling field is invisible but has a default value satisfying the condition, then the dependent page/component **will still be displayed**.\
\&#xNAN;*Example*: a radio field has the first option "YES" selected by default and we conditionally show another field exactly when it is "YES" – even if the radio field is hidden, the default value *"YES"* will still cause the dependent field to be revealed. Such situations must be handled consciously, e.g. by setting no default answer for the radio field.
* **Order and consistency:** Keep the structure tidy – do not create unnecessary empty steps, do not place single fields on separate pages if it is not necessary (it is better to group fields thematically within one page so that the user does not have to click "Next" for every small piece of information). Also try to ensure that each step logically corresponds to one process topic – this will make it easier both for the user to understand the progress and for you to expand the application later.
* **Translation naming:** If the form is bilingual, make sure the translation key naming for steps and pages is consistent. As a rule, the pattern `StepX.title` and `PageX.title` . In the tab **Translations** 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**](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/komponenty-rozszerzone/komponenty-zlozone.md) instead of duplicating those fields manually everywhere. This will make changes easier and help maintain consistency.
* **Parking the application:** If your business process allows parking (saving a draft) before submission, make sure it is handled correctly in the form. By default, Eximee lets the user park the application using the “Save and come back later” button (if the implementation includes it). However, this does not apply to steps after the save point – there, parking the application is impossible, so you do not need to do anything extra.
## Debugging steps and pages – checklist
Despite your efforts, complex applications may have 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. The condition may always be false (e.g. a typo in a 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 a child 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, it is almost certainly missing **Listening**. Check whether the dependent component has **Listening** added to that field. If not, add the missing links and test again.
3. **An element is displayed even though 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 the operators (e.g. using `==` instead of `!=`) or data types (are you comparing text with a number?).\
When debugging conditions, it can help to temporarily add a text field to the form and set its text to the result of the problematic expression – then you can see live what that expression returns.
4. **Problems navigating between steps:**\
If the “Next” button does not respond or the user gets stuck, make sure that there is at least one **visible** page in that step. It may happen that all pages in the step have been hidden by conditions – then, after completing the previous step, the system may have nowhere to go. Solution: either ensure that at least one page always appears, or conditionally skip the entire step (a condition on the step instead of on each page separately).
5. **Cannot edit the form (edit icon is greyed out):** The form was probably locked by the draft mechanism – for example, another user edited it and did not save it.\
The lock can be removed as described in the section *Draft – draft / working copy*. In Eximee Designer, in the form list view, the locked artifact is marked with the appropriate information and an option to take over the draft.
6. **Checking process links:** When you use EximeeRouter2, verify the process name and business key mapping in the Save Point configuration. An incorrect process name may cause nothing to happen after submission (the application will be saved, but the process will not start). In the system logs, look for messages related to process start-up.
7. **Logs and developer mode:** If you run into hard-to-diagnose problems, use the browser logs (JS console) and the Eximee server logs. Verify in the tab **Source** that the properties of steps and pages there match expectations (this will help catch, for example, accidentally overwritten identifiers or missing entries).
8. **Use the FAQ:** If in doubt, see the document **Eximee Designer FAQ** – many common problems are described there along with solutions. For example, it explains why a dependent component may appear even though the control is hidden (default value), or what to do when changes in a composite component are not visible in the application.
Applying the checklist above should help you 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 the conditions (e.g. temporarily set them to `true`/`false` in order to isolate the influence of other factors) and adding diagnostic elements (technical fields, text fields, etc.).
## Links to other documentation sections
The “Steps and pages” mechanism is closely connected with other aspects of building an application in Eximee. For a full understanding and correct configuration, it is also worth reading the following documentation topics:
* **Processes and EximeeRouter2** – if the form is part of a larger business process, read the document [**Processes**](/documentation/documentation-en/budowanie-aplikacji/proces-biznesowy/proces-jako-logika-biznesowa.md). 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 you make better use of save actions in the **Save Point** (e.g. passing process variables, exception handling).
* **Translations** – the **Translations** tab in the editor allows you to add translations for text used in the form (including page titles, button labels, etc.). Remember that keys such as *titleKey* or *labelForNextOrSubmitButtonKey* require adding corresponding entries here; otherwise the content we are interested in will not be shown to the user.
* **Styling and UX** – the steps mechanism affects the user experience, so it is worth learning about the **styling** options for the form. In the styles documentation you will find information on how to globally customize the appearance of the step bar, navigation buttons, or page layout. For example, there are *platform styles* and the option to add your own CSS stylesheets to the application. Relevant sections (e.g. *Component styling*) show examples of using style properties.
* **WCAG – accessibility** – if the project requires compliance with WCAG, be sure to read the dedicated documentation **WCAG**. It contains guidelines for building accessible forms, descriptions of features such as *ariaLabel/Description*, the accessibility audit in the editor, and tips for creating screen-reader-friendly components. In the context of steps and pages, make sure, for example, that each step is announced logically (if the step bar is hidden, consider adding hidden headings on pages informing the user about the current stage). The flag *role=form* mentioned earlier also relates to WCAG recommendations.
In conclusion, the “Steps and pages” mechanism is the backbone of every application in Eximee Designer – mastering its principles will let you build rich yet clear forms. Use the documentation and the tips above while working, and your applications will guide the user correctly from the first step all the way to the thank-you page in a way that is friendly and consistent with business requirements.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/kroki-i-strony-formularza.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
