{"title":"How POS design works","slug":"how-pos-design-works","url":"https://support.storeconnect.com/articles/how-pos-design-works","url_markdown":"https://support.storeconnect.com/articles/how-pos-design-works.md","subtitle":null,"summary":"Explains the three records every POS screen is built from, action groups, layouts, and views, what changing each one takes, and how far you can go without writing code. Read this when assessing how much of the register you can reshape for your store.","type":"Help_Documentation","video_url":"","keywords":"pos design, pos customization, action groups, pos layouts, pos views, navigation, custom screens, pos architecture, action items, layout filters, design your own pos, ai agent pos, no code pos","last_modified":"2026-10-07T05:47:34+0000","body_markdown":"There are many ways you can design your point of sale in StoreConnect. Almost every screen in the POS can be built how your business wants it. Menus, pages, lists, everything.\n\nThis topic talks you through the structures behind the POS design, so you can decide what you want to change and how.\n\n## The three building blocks of POS\n\n| Building block | What it controls | How to change |\n| --- | --- | --- |\n| [Action group](pos-action-groups) | Navigation: what staff can tap, and what happens when they tap it | Configure Salesforce records, no code |\n| [Layout](pos-layouts) | A screen of records: which fields appear, how they are filtered, and which actions are available | Configure Salesforce records, no code |\n| [View](pos-views) | Your own markup in place of the standard rendering | A template written in HTML, CSS, JavaScript, and Liquid (some code)|\n\nYou can design a complete register using only action groups and layouts by configuring records. But if you want to change anything more substantially, you need to use POS views as well. A view can achieve what the combination of layouts and filters cannot. \n\nLet's start with the basics, and learn more about views below.\n\n## Action groups\n\nAn action group is a set of tappable actions on a POS register. The sidebar down the left of the POS, the row\nof icons across the top, and the home screen grid of category tiles are all `list` or `grid` action groups.\n\n![Sidebar menu](https://res.cloudinary.com/hzkr6fi81/image/upload/v1790136670/media/Action_groups.png)\n\nEach item in a group is a **POS Action Item** with its own **Display Name**, **Icon**, and\n**Color**. Its **Action** field sets what happens when staff tap it: such as open a layout, open\nanother action group, open a view as a modal, etc.\n\nYou can also create nested menus using **Child action groups**.\n\n## Layouts\n\nEach screen on the register is based on a POS layout. So when you tap through to a page and see a list of records or a payment screen, this is a **POS Layout** you can change. \n\nThere are four layout types:\n\n| Page Type | Shows | Typical use |\n| --- | --- | --- |\n| `list` | Many records, as rows | A customer list, an order list |\n| `grid` | Many records, as cards | A product catalog browsed by touch |\n| `record` | One record, read only | An order summary |\n| `form` | One record, editable | Creating a customer, the End Shift form |\n\nA `list` and a `grid` show the same data two ways. Use a grid where staff pick by sight,\nsuch as products with images, and a list where they scan text.\n\n![POS product in list and grid view](https://res.cloudinary.com/hzkr6fi81/image/upload/v1790137145/media/pos-grid-and-list-layout-side-by-side.png)\n\n:::note\n\nA **grid layout** and a **grid action group** are different things with similar names. A\ngrid layout shows records as cards, pulled from the object the layout is bound to. A grid\naction group shows action items you defined by hand. A product catalog is a grid layout; a\nhome screen of tiles is a grid action group.\n\n:::\n\n### Actions on layouts\n\nA layout supports three actions:\n\n-   **Primary action** is the main button on the screen, such as **New Customer** on a\n    customer list.\n-   **Secondary action** sits in the corner, for actions staff use less often, such as **Cancel**.\n-   **Record action** an action that occurs when staff interact with a record. For example, on a product grid,\n    tapping on an item adds it to the cart.\n\n### Filters and hidden filters\n\nYou can use filters and hidden filters to display records a certain way to staff. Hidden filters can't be interacted with, and are used to manage what is displayed on a page.\nExplicit filters enable staff to interact, to refine lists and drill into product categories and sub-categories.\n\n## Views\n\nA **POS View** is the most customizable element in POS design, because it is essentially an HTML template that can contain HTML, CSS, JavaScript, and Liquid.\nThis means setting up and maintaining views requires some front-end coding expertise.\n\nThere are four places a view can go, and each one hands your template different data to work\nwith:\n\n-   **On a layout**, replacing the records list. The search bar, filters, and buttons stay put.\n    Your template runs once for the screen and gets every record on the page, so on a `grid`\n    layout you draw the whole grid rather than one card.\n-   **On a layout field**, replacing how one field renders. The rest of the screen stays\n    standard and one column is yours. This is the one that runs per record.\n-   **On an action item**, replacing what the button itself looks like. It doesn't change what\n    tapping the button does.\n-   **Opened by name from an action**, where `modal:open:view` shows your view as a modal and\n    `nav:view` opens it as a full screen. These reference the view's **Identifier** instead of\n    pointing at it with a lookup field.\n\nSee [POS views](pos-views) for what each of those hands over, and for how to create and update\nthe records.\n\nViews can incorporate built-in POS actions through the [`scAction`](pos-sc-action) function, such as\nadd to cart, start checkout, print a receipt, or save a record.\n\n## Design implementation\n\nThere's a couple of ways you can implement POS designs.\n\n-   **Build them yourself.** Create and edit the records in Salesforce.\n-   **Have an AI agent build them.** An agent with the StoreConnect AI skills and an\n    authenticated Salesforce CLI can do most design tasks based on plain language prompts. See [Build POS with an AI agent](pos-with-ai-agents).\n\nBoth routes produce the same records, so you can start with an agent and carry on by hand,\nor the reverse."}