Paged layouts are ideal when you have a very large number of fields on a layout and wish to separate them into logical groups which the user can page forward and back through, using forward and backwards buttons. Compare this to the use by users, of accordion folds that open and close individual sections of the screen. Paged layouts are also ideal to use on mobile device layouts where there is only room on a device to display a handful of fields at a time, before the user has to scroll up and down.
Paged layouts have several important criteria associated with their use:
- Only one page within a sequence may be visible at any one time. This is termed the active page.
- Each page is defined with two fields, one beginning with the characters PAGE_PRE_ and one beginning with the characters PAGE_POST_. For example, fields defining a page might be named PAGE_PRE_ORDER_INFO and PAGE_POST_ORDER_INFO. An obvious point is that each add or edit layout that contains pages, should have at least two pages defined. The two fields surround all the fields or embedded layouts that compose each page
- Each page within the sequence may optionally have a title. This is defined within the field's data dictionary entry within the Help Text. If not title is defined, pages will be titled Page 1, Page 2, etc. The title is displayed at the top of the page within the layout
- The PAGE_PRE_ and the PAGE_POST_ fields must extend the complete width of the layout that uses them
- Each page may contain any number of fields or may contain an embedded layout. Note that you might have some fields before or after the last page you have defined. If you configure the layout in this way, then the fields before the first PAGE_PRE_ and after the last PAGE_POST_ fields will always be visible to the end user
- A complete page, within a sequence of pages, may have a visible if layout cell attribute associated with it, allowing the page to be skipped upon data entry, dependent on the values controlling the visible if attribute chosen by the end user
- The order of the pages defined within the add or edit layout is significant. The order defines the sequence with which the pages will be presented to the end user
- When an add or edit screen is first opened by an end user, the first visible page is opened. All other pages will be closed. A visible page is one where at least a single field is visible - fields are subject to the usual constraints such as security permissions
- Care should be taken when using allowed value type relationships, to ensure the parent field is set on the same page, or a prior page to the child field. It would be difficult for the end user to navigate back up the pages to enter a child value in a field
- If the current page which a user is viewing becomes invisible, due to workflow constraints, the first, visible previous page becomes the active page and is made visible
- Care should also be taken with required fields within pages. These fields will still be required when the user submits the issue, even if they are not on the current active page
- Nested pages are not supported. This implies that each PAGE_PRE_ field must be followed by its corresponding PAGE_POST_ field, before another PAGE_PRE_ field is encountered
- You cannot create pages within "Selected By" layouts. This is not a supported configuration
- You cannot create pages nested within accordion folds. This is not a supported configuration
- You cannot create pages nested within shaded regions. This is not a supported configuration
Paged Layouts & Accordion Folds
It is not recommended to nest Accordion Fold fields within Paged layouts, or vice versa. This does not provide a very usable user interface, and you might encounter some unexpected behavior.
