Customize registers for different purposes

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.

All registers share one catalog, one customer database, and one order history, so a customer served at any of them has a single record.

Use cases

• Separate counters - General sales, trade and B2B, returns, customer service, or a VIP experience.
• Installation and service - where staff work from pre-booked fulfillments rather than products.
• Training - so new staff can learn in the interface they will actually use.

What differs between registers

Two mechanisms give a register its own character, and the first is much the stronger.

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

Two things do not vary, and planning around them saves rework:

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

Example

A 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:

• Front counter takes walk-in sales. No station is assigned to it, so its fulfillment screens stay empty.
• 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.
• 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.
• 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.

Setup steps

1. Create one Register per job on the outlet, named for the job. See Add a register to an outlet.
2. 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.
3. 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.
4. Set the discount ceiling on each Outlet User Type. See Add a POS user.

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

Prefill the sign-in screen

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

https://shop.example.com/pos?username=sam%40example.com&register=<outlet register code>

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

The PIN is never prefilled. The operator always types it.

:::warning A 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. :::

Stores that share a domain

Where several stores are served from one domain, add a third parameter:

&storage_key=<store path>

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

Set up a training register

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

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

You can switch between a training and a production register by changing the browser URL on the device. See Configure your POS access URL.

Results

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