> 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 basic elements of the form structure in Eximee Designer, which allow you to organize 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 application summary), and **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 tab.**

## “Steps” tab – editing the form structure

The step and page structure is managed in the **Steps** application editor. After opening a 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 assigned) and **visibility condition** (a conditional expression that determines whether a given step/page should be displayed).\
\&#xNAN;*Note:* these conditions are not executed in this view, they are only shown for information.

To edit the structure, switch the **Steps** tab to edit mode (pencil icon – **Edit process**) – it may be necessary first to release any working lock (draft) of 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.* 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 within that step (a step cannot be empty).
* **Deleting a step** causes all pages it contains to be deleted.
* **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 item). For a page, the “Open” option is additionally available, which takes you to editing that page's content in the **Request**.

> **Tip:** The progress bar (steps) 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**, 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** tab, the same properties appear under their technical identifiers:

* id – unique step identifier (internal technical name). By default, steps receive IDs in the form `Step1`, `Step2` etc. Its editing is available only 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** after finding 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, saved as a logical expression. If the condition is **not met**, the given 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 (for 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 appropriate step.\
  For example, for a step to be visible only when the user has checked a checkbox with ID `GesCheckbox1`, the condition may look as follows:

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

This condition will return "true" if Checkbox1 is checked, which will cause the step for 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. To make step visibility refresh dynamically, for all pages in that step you need to:

* set the same visibility condition,
* add listening to the components used in the condition (tab **Request** → Page properties → section **Interactions)**.
  {% endhint %}

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

## 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 **Request** (e.g. by clicking the page name in the Steps tab list or choosing “Open”) and then click 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 **Steps**, but most settings are available only in page editing.

Below is a summary of the 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 a new page is created and 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 address while completing the application.
* **Business identifier (mid)** – optional “friendly” page identifier. By default **mid** is the same as **Id** the page, but you can assign your own business name. It is also editable in the **Steps,** by clicking the first column in the page row. **Mid p**should be unique.
* **Title** – page title displayed 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. Works similarly to the *titleKey* step key – allows you to define the title in different languages (default value is e.g. `PageX.title` (where X is the page number). In the **Translations** you can add the appropriate entries for this key.
* **Page number** – ordinal number indicating which page of the application the given screen is. This is a read-only field (the system numbers pages itself in the order they appear in the structure).
* **“Next/Submit” button label** – allows you to define custom text for the navigation button used to go to the next page or submit the application, visible on that page (e.g. “View summary” instead of “Next”). By default, the button has the label “**Next**” or “**Submit** **request**” 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 a custom button label is not defined for the page, the field uses the label provided from session variables `nextButtonText` / `submitButtonText`, and then global platform keys are used (`iew.navigation.next` / `iew.navigation.submit`).

#### Layout

* **Number of columns** – the field shows the number of columns defined for the given form. The field is not editable from the **Application** The change in the **Source** has been described in [Page editing](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/edycja-stron.md)

#### Data quality

* **Visibility condition** – formula (expression) that determines whether the page should be shown to the user. If the condition returns `false`, the page will be skipped when displaying the application (the user will not see it). Conditions are written as JavaScript expressions – we can use functions such as `getValue("componentId")` (getting the value of a component with the given identifier) or `isVisible("componentId")` (checking component visibility). More examples are described in [Expression language for defining conditions (conditions from 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 selection field has a specific value:

```javascript
// Page visible only when the value "A" has been selected in the "applicationType" field
getValue("applicationType") == "A"
```

* **Validators** – field that allows you to 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 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** – mechanism responsible for **dynamic refreshing** of the page/component/variable state 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, you need to add that component to the **Listening**. This way, changing the value of that component will cause the condition to be recalculated/refreshed and possibly show/hide the page. In the **Listening,** you can specify multiple components.\
  Editing is done through the list window – after clicking the **List,** button a popup appears with a list of available components. You can search for them by entering either **Id** or **mid**. Already selected components are also visible in the popup - the same one cannot be selected twice.\
  \&#xNAN;*Example:* if the page has **Visibility condition** dependent on the field `contractCheckbox`, you need to add `contractCheckbox` to **Listening** of this page. Similarly for step conditions – because a step does not have its own listening attribute, the components determining its visibility are added to the listening of the first page of the step.

#### Styling

* **Style name** – list of CSS styles assigned to the page. It allows you to give the page (and all its elements) an individual look through CSS styling. 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 can be found in the documentation in section* [Form styles and component styles](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze.md)*.)*
* **Sticky next button (customPositionedNavbarCondition)** – condition for the specific behavior of the navigation button “Next”/“Submit”. This is a function used mainly in native mobile applications – it can, for example, make the button always visible at the bottom of the screen (pinned) if a given condition is met. After setting the condition to *true*, for the given page the navigation button will change its display mode.\ <sub>*(Availability of the functionality depends on the license and may not be available in all deployments)*</sub>
* **Hide the cancel button ("X")** – flag indicating 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. Checking this option will hide it on the given page.\ <sub>*(Availability of the functionality depends on the license and may not be available in all deployments)*</sub>
* **Hide back button** – 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.\ <sub>*(Availability of the functionality depends on the license and may not be available in all deployments)*</sub>
* **Hide application title** – flag determining whether the title of the entire application is 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 we simply want to save space, we can hide the default title by checking this option.\ <sub>*(Availability of the functionality depends on the license and may not be available in all deployments)*</sub>

#### WCAG

* **Page contains a form** – flag indicating whether the page should be treated by assistive technology as a standalone form. Enabling this option will add the `role="form"`attribute to the page container, which can be required to meet WCAG accessibility standards (especially when there are multiple independent forms within a single application). Details on 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 inside the main form of the entire application anyway), but it can be useful in unusual scenarios.

#### Other

* **Curtain** – configurable message displayed at the top of the page in the form of a curtain. It can be used, for example, to block interaction with the rest of the form until the user performs some action or simply to display a highlighted announcement. **Curtains** can be used as information banners. This property allows you to choose a previously defined **Content (TextContent)** as the message or enter a text message.\ <sub>*(Availability of the functionality depends on the license and may not be available in all deployments)*</sub>
* **Bottom bar (bottom bar)** – an additional bar at the bottom of the page (mobile apps only) used to present, for example, a collapsible section with additional information or actions. There are several properties configuring this bar:

  * *Should text expand? (expandable)* – whether the bottom bar should contain **expandable content** (i.e. 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 can be e.g. “Read more”. By entering here, for example, `bottom.expand`, an appropriate entry must be added in translations (e.g. *bottom.expand = "Show more information"* ). Similarly, *Collapse button text (hideToggleTextKey)* – key for the text of the option to collapse the bar (e.g. “Hide details”).
  * *Bar visibility condition (visibleCondition)* – logical condition determining whether the bottom bar should be shown on the given page at all. If, for example, the bar should be visible only for new customers, an appropriate condition can be entered here.
  * *Expanded content (topTextContentName)* – name of the artifact **Content (TextContent)**, 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 the **Content** component
  * *Collapsed content (bottomTextContentName)* – similarly, the name of the artifact Content with 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 with the content of *topTextContent*.

  <sub>*(Availability of the functionality depends on the license and may not be available in all deployments)*</sub>
* **Login required condition (loginRequiredCondition)** – condition determining the need for the user to log in before the page is displayed. If a condition is defined here (e.g. `getValue("isCustomerLoggedIn") != "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.

*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 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 a few best practices that will make the application easier to maintain and ensure correct logic behavior:

* **Thoughtful naming:** The names of artifacts (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 choose names that reflect their content or role. Avoid leaving default names such as *Page1* – it is better to replace them with, for example, *AddressData* or *Summary*. This makes it easier to navigate the structure, and the business identifiers appearing, for example, in conditions, will be more readable.
* **Unique identifiers:** Each step, page and component should have a unique **mid** (business identifier). The system does enforce uniqueness within one form, but if you duplicate artifacts or copy form fragments, it is easy to miss duplicated identifiers. Duplicate **mid** can lead to incorrect operation of conditions or listening. When duplicating elements, always check and change **mid** to a unique one. Similarly, translation keys – do not use one key for two different texts.
* **Readability and modularity of conditions:** When creating complex conditional expressions, keep them readable. Use parentheses and naming conventions to clearly express the 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 one session variable or a technical field. For example, you can add a **technical field** with **mid** `isCustomerVIP` with a default expression evaluating customer data, and then in the conditions of different steps refer only to `getValue("isCustomerVIP")`. 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 **technical field,** by selecting the appropriate option in **Properties** of the text field - in the section **Security**. 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 scenarios** of application completion. Make sure that steps and pages appear and disappear according to the assumptions in response to user input. 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 where a condition refers to a field with a default value: if the controlling field is invisible but has a default value that satisfies the condition, the dependent page/component **will still be displayed**.\
  \&#xNAN;*Example*: a radio button field has the first option “YES” selected by default and conditionally shows another field precisely when it is “YES” – even if the radio button is hidden, the default value *"YES"* still causes the dependent field to appear. Such situations need to be handled consciously, e.g. set no default answer for the radio button.
* **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 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 topic of the process – this will make it easier for the user to understand progress and for you to expand the application later.
* **Translation naming:** If the form is bilingual, ensure consistent naming of translation keys for steps and pages. Usually the pattern `StepX.title` and `PageX.title` . In the **Translations** is used – it makes it easy to 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 and consistency easier to maintain.
* **Application parking:** If your business process allows parking (saving a draft) before submission, make sure it is handled correctly in the form. By default, Eximee allows the user to park the application using the “Save and return later” button (if provided by the deployment). However, this does not apply to steps after the save point – parking the application there is impossible, so you do not need to do anything extra.

## Debugging steps and pages – checklist

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

1. **Step/page does not appear at all:**
   * Check the step visibility condition and all parent elements. Perhaps the condition is always false (e.g. a typo in a field name in the expression causes it to always return **false**).
   * Make sure that the identifiers used in the visibility condition exist and are correct.
   * Check whether the given step has been 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, then almost certainly **Listening**. Check whether the dependent component has **Listening** added to this field. If not, add the missing bindings and test again.
3. **The 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 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 – then you will see “live” what the expression returns.
4. **Problems navigating 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 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 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 section *Draft – draft/working copy*. In Eximee Designer, the form list view shows an appropriate message and an option to take over the draft for a locked artifact.
6. **Checking process bindings:** When using 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 is saved, but the process does not start). In the system logs, look for messages related to process startup.
7. **Logs and developer mode:** If you encounter hard-to-diagnose problems, use the browser logs (JS console) and Eximee server logs. Verify in the **Source** tab whether the step and page properties there match expectations (this helps catch, for example, accidentally overwritten identifiers or missing entries).
8. **Use the FAQ:** If in doubt, check the document **Eximee Designer FAQ** – many common issues 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 step and page mechanism. If the problem is unusual, it is worth analyzing it step by step, simplifying conditions (e.g. temporarily setting them to `true`/`false` 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 related to other aspects of creating an application in Eximee. For a full understanding and correct configuration, it is also worth reviewing 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 run 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** – tab **Translations** in the editor, it enables 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 here, otherwise the content we are interested in will not be displayed to the user.
* **Styling and UX** – the step mechanism affects the user experience, so it is worth learning the possibilities **of styling** the form. In the styles documentation you will find information on how to globally customize the appearance of the steps bar, navigation buttons, or page layout. For example, there are *platform styles* and the ability 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 on building accessible forms, descriptions of functions such as *ariaLabel/Description*, 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 logically announced (if the steps bar is hidden, consider adding hidden headings on pages that inform about the stage). The flag *role=form* mentioned earlier also refers to WCAG recommendations.

To conclude, the “Steps and pages” mechanism is the framework of every application in Eximee Designer – mastering its principles will allow you to build extensive yet clear forms. Use the documentation and the above tips while working, and your applications will guide the user properly from the first step all the way to the thank-you page in a friendly way and in line with business assumptions.


---

# 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=<question>&goal=<endgoal>
```

`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.