Skip to main content

Devices, sign-in and stores

Devices​

The app is the same on every device, with the same screens and the same modules.

DeviceRequirementScanning
iPhone and iPadiOS 16.4 or latercamera
Android phones and tabletsAndroid 8.0 or latercamera
Zebra rugged handheldsAndroid 8.0 or later, with DataWedgehardware trigger, and camera

The app runs in portrait on both phones and tablets. It asks for two permissions: the camera, to scan barcodes, and notifications, to receive push notifications. Without the camera a Zebra handheld still scans with its trigger; without notifications everything works except the push itself. See Scanning and quantities for the Zebra set-up, which the app does itself.

Signing in​

The first start takes three screens:

  1. Welcome to HiiRetail asks for the Tenant Alias: the part of the company's Hii Retail login address before .hiiretail.com. For acme.hiiretail.com it is acme. The app remembers it.
  2. Sign In shows the company's own Hii Retail login page, with whatever sign-in methods the tenant has set up in Identity and Access Management. The app has no login form of its own.
  3. Select store lists the stores. The colleague picks the one they work in. With Set as default store ticked, the app opens on that store from then on; unticked, it asks again the next time the app starts. A tenant with only one store skips this screen.

Signing in takes three screens the first time. Welcome to HiiRetail asks for the Tenant Alias, the part of the login address before .hiiretail.com, here acme. Sign In then shows the company's own Hii Retail login page. Select store lists the stores and Set as default store makes the choice stick; with only one store the app skips this step.

After that the colleague stays signed in. The app renews the session in the background, and on its own when it returns to the foreground. If the company revokes the sign-in, the next call sends the colleague back to the login page.

Without a connection the session lasts 7 days from the last time the app was online. Within those days the app starts and works offline as normal. After them it still shows what it has, but takes no new work until the handset is back online and the colleague has signed in again. See Working offline.

The session is kept in the device's secure storage: the Keychain on iOS and the Keystore on Android.

The Home screen​

The Home screen. At the top, the store the handset works for. Under Notifications, a live summary of the open work: Orders to pick 3, Deliveries to receive 1, Stock counts active 1, each opening its module; the bell mutes notifications. Below are eight tiles, one per module, and Settings and Account at the bottom.

  • Current Business Unit is the store every module works for.
  • Notifications summarises the open work in the store: orders to pick, deliveries to receive, stock counts in progress, and recent order changes. Rows with nothing to do are hidden, and a tap opens the module. The bell next to the heading mutes push notifications on this handset. See Notifications.
  • The tiles open the modules: Goods receivable, Store transfers, Click & Collect, Store Layout, Stock counting, Stock correction, Stock events and Control tasks. See Modules.
  • Settings holds the store and the offline data. Account shows who is signed in and has Logout.

The menu (☰) in the top corner lists the same modules, plus Change store, Log out and the app's version number.

Changing store​

Staff change store under Settings → Change Business Unit, or Change store in the menu. The app then clears what it had cached for the previous store and loads the new one's.

Settings has one more section, Offline Data:

  • Refresh offline data downloads the reference data the app keeps for offline use, such as the reason codes, again. Do this after the reason codes have changed.
  • Pending sync lists work that is still on the handset. See Working offline.

What a user needs access to​

The app has no roles or permissions of its own. It calls each service with the signed-in user's token, and the service decides, using the user's permissions in Identity and Access Management for that store. So a user can do in the app exactly what their permissions allow them to do through the services' APIs, store by store.

When a permission is missing the service refuses the call and the app says so, for example "You do not have permission to perform stock corrections." Give each user group the permissions of the services behind the modules it uses; the table on the introduction lists which service is behind each module.

🛑 Notifications need their own permissions. To register a handset for push and to read the notification list, the user needs ins.notification.list, ins.notification.subscribe and ins.notification.unsubscribe for the store. Without them the app works, but the handset is never registered and no notification arrives, and nothing on the screen says why. Check these first when a store reports that notifications do not come.