{"title":"Customize registers for different purposes","slug":"purpose-built-registers","url":"https://support.storeconnect.com/articles/purpose-built-registers","url_markdown":"https://support.storeconnect.com/articles/purpose-built-registers.md","subtitle":null,"summary":"Give each job its own register, such as sales, trade, returns, service, or training. Covers what genuinely differs between registers (fulfillment stations and views that branch on the register) and what does not, how to prefill the sign-in screen, and running a training register on a sandbox.","type":"Help_Documentation","video_url":"","keywords":"register experience, POS login URL, prefill register, username parameter, register parameter, storage_key, shared domain, switch registers quickly, bespoke POS, custom register, role based POS, B2B register, returns desk, service desk, VIP, training register, sandbox training, onboarding, staff training, reduce errors, POS layouts per register, consistency","last_modified":"2026-10-07T05:47:34+0000","body_markdown":"Staff sharing one register lose time switching between jobs that have nothing to do with each other. Use this process to give each register a job, so a returns desk, a trade counter, and an install desk each handle their own work.\n\nAll registers share one catalog, one customer database, and one order history, so a customer served at any of them has a single record.\n\n## Use cases\n\n-   **Separate counters** - General sales, trade and B2B, returns, customer service, or a VIP experience.\n-   **Installation and service** - where staff work from pre-booked fulfillments rather than products.\n-   **Training** - so new staff can learn in the interface they will actually use.\n\n## What differs between registers\n\nTwo mechanisms give a register its own character, and the first is much the stronger.\n\n-   **The work it handles.** A **Fulfillment Station** is assigned to a register, so that register sees only the fulfillments its stations own. Each station carries its own display name, status flow, offline behavior, and fallback station, and each can be pinned to its own printer. A **Register Fulfillment Category Station** record overrides which station a category routes to on that register, so two registers in one outlet can send the same category to different places. See [Configure POS fulfillment station routing](pos-fulfillment-station-routing).\n-   **What a screen shows.** A **POS View** can read `current_register`, so one view attached to a layout renders different fields on a trade register and a retail one. Branch inside the template. See [POS views](pos-views).\n\nTwo things do not vary, and planning around them saves rework:\n\n-   **The home grid and the layouts are org-wide.** **POS Action Groups**, **POS Layouts**, **POS Layout Fields**, and **POS Layout Filters** are addressed by **Identifier** alone and carry no store, outlet, or register field. Every register in the org opens the same `home` grid and loads the same layouts. The one variation is at outlet level: where no `home` action group exists, a register falls back to the product category set on its **Outlet**.\n-   **Permissions.** Discount ceilings come from the **Outlet User Type**, so what a person can do is governed by who they are, not which register they stand at.\n\n## Example\n\nA homewares store runs four registers in one outlet. All four open on the same `home` grid and load the same layouts, and they still do different jobs:\n\n-   `Front counter` takes walk-in sales. No station is assigned to it, so its fulfillment screens stay empty.\n-   `Trade` serves account customers. A view on the customer layout branches on `current_register` to show purchase order and account terms, which the other three do not display.\n-   `Returns` handles exchanges. It runs the same screens as the front counter, and what differs is the staff signed in to it and the ceiling on their **Outlet User Type**.\n-   `Install desk` owns the `Installation` station, so it sees only fulfillments routed there, advances them through that station's status flow, and prints its dockets on the printer pinned to that station.\n\n## Setup steps\n\n1.  Create one **Register** per job on the outlet, named for the job. See [Add a register to an outlet](add-a-register).\n2.  Create a **Fulfillment Station** for each register that owns its own queue of work, and set the station's **Register**. Add a **Register Fulfillment Category Station** record where one register needs a category routed somewhere other than the outlet default. See [Configure POS fulfillment station routing](pos-fulfillment-station-routing).\n3.  Where a screen has to show different fields on different registers, attach a **POS View** to the layout and branch on `current_register` inside the template. See [POS views](pos-views).\n4.  Set the discount ceiling on each **Outlet User Type**. See [Add a POS user](add-a-pos-user).\n\nRefer to products by **Product Code**, never by Salesforce ID, so the same setup moves from a sandbox to production untouched. See [Deploy POS configuration to production](deploy-pos-configuration).\n\n## Prefill the sign-in screen\n\nOnce an outlet has several registers, signing in to each one becomes the slow part. The sign-in screen reads two values from the URL, so a link can arrive part-filled.\n\n```\nhttps://shop.example.com/pos?username=sam%40example.com\u0026register=\u003coutlet register code\u003e\n```\n\n-   `username` prefills the user field. URL-encode it, because a raw `+` decodes to a space, so `sam+pos@example.com` must be written `sam%2Bpos%40example.com`.\n-   `register` prefills the register code field. That code belongs to the **Outlet**, not to one register, so a single link covers every register at that location. Which register the device takes is still chosen after sign-in.\n\nThe PIN is never prefilled. The operator always types it.\n\n:::warning\nA register code is a shared secret for the whole outlet, which is why it must be at least 20 characters. A URL carrying one puts it into browser history, bookmark sync, and anywhere the link is later pasted. Keep these links to managed devices, and change the outlet's register code if a link escapes.\n:::\n\n### Stores that share a domain\n\nWhere several stores are served from one domain, add a third parameter:\n\n```\n\u0026storage_key=\u003cstore path\u003e\n```\n\nLocal storage is scoped per origin, so two stores on one domain otherwise compete over the same register pairing. Set `storage_key` on every link to that store, because a link without it lands in a different storage scope from a link with it.\n\n## Set up a training register\n\nA training register runs the real interface, with the real layouts and actions. You can also add guidance material to the view itself, such as a short video beside the task it describes.\n\nTraining registers use a sandbox rather than the trading store, which has the same setup as production. Staff learn on realistic layouts, products, and prices they will use, while nothing they ring up moves real stock or shift totals.\n\nYou can switch between a training and a production register by changing the browser URL on the device. See [Configure your POS access URL](configure-pos-url-access).\n\n## Results\n\nEach register now shows only the fulfillments its stations own, and any register with a branching view shows the fields for its job. Orders from all of them report together in Salesforce, and trainees have a register that cannot affect real stock or shift totals."}