All About a Topic
Library All Articles Selling Common selling features Serial Numbers (selling) Web Browser Selling Advanced Selling More specialised selling Delivery Addresses Product/Case Selling Messages Reminders & Contacts


Accounts Stock Levels Barcodes MYOB


Receipt Formats (sales) Email Purchase Orders Label Formats PreCanned Reports POS Security

POS Security

This page is about security for POS users, ie users that login to the POS and sell etc. Security on web pages and APIs is not covered here.

You can configure Fieldpine to use login based security. This means staff must login to perform certain tasks. Security is off by default, but turns on automatically when you create your first (active) staff record

Key Terms

Login Name (aka staff member, username) This is the person logging into system, eg "Bob" or "Anita". The login name is what is recorded against sales and other itesm

Rights. Security rights are what you grant users permission to do. For example you grant the user "Bob" the right to "Void Sales". Imagine that many functions in POS have a gateway in front of them, and only users with the necessary right can pass through the gateway.

Roles. Allocating individual rights to users is cumbersome as there are a lot of rights available. Instead you can creates a "role" which is given rights and then the role is allocated to users. For example, you might create the role "trusted employee". To this role you might give the rights "define new barcode and edit completed sales". You then allocate the role to users, such as Bob and Anita, but not Leslie. This means you typically only need to allocate a couple of roles to users based on what they do, saving a ton of effort.

Employees While not part of security, the POS can also record employees. Specific products when sold can then prompt for an "employee" to record against that saleline, typically for commission purposes. Employees and staff are seperate as "staff" are Point of Sale users, while "employees" can include non counter people. This is mentioned here to clarify that employees are not part of security.

Common Configurations

In general security is enabled for the following reasons

  • You wish to restrict some operations to certain staff only
  • You want an audit record of who did what when
  • You wish to record sales by staff member for incentive programs and commissions

The first option to decide is how long before the system times out an idle session. Too short and it might negatively affect selling by logging out while pausing briefly to pack items. Too long and the purpose of security might be negated. Keep in mind that staff can also manually logout.

An often used setup is to set the timeout to around 60-120 seconds.

An alternative, is to use a shorter timeout, but check the option, "disable timer while sale active". This does exactly what it says, and is most useful if your primary aim


The POS can automatically login during startup if the Windows login name is linked to an account. When autologin is used, timeouts are blocked temporarily.

If an autologin user logs out of the Point of Sale, then everything resets to normal operation as if autologin had not been invoked.

If autologins are enabled, you can login to the Windows account, and then login to the POS account. Then issue the quickcode "enable sso for me" this will link the current Windows login to the POS login. NB. This code may not work in remote stores depending on site configuration

Hidden Functionality

Some options are not visible within the staff configuration screen either because they are deemed insignificant for most retailers or have not yet been tested enough for general release

Login Photos

If the setting LoginPhoto (default 0/no) is defined, then the POS will capture a photograph of the person using the register. This attempts to use the camera facing the operator if present.

Active Timeout

The timeout parameter is a single value and applies both when sales are present and not present. The setting TellerTimeoutActive (default -1 / disabled) can be defined and is used as the timer when a sale is active. The standard TellerTimeout is then used for when sales are not active.

This can be used where you want a reasonable timeout when sales are active (say 300 seconds), but should logoff quickly when sales are not present (say 20 seconds) Having two timers means that if the staff member completes a sale, they can create another within 20 seconds and not relogin. This is useful if they have a queue of customers, but still ensures if they walk away from the checkout the POS locks reasonably quickly.

Requires Pos Version P2340 or higher

AutoLogin Exclude List

If you are using autologin, then you may wish to exclude certain Windows logins from autologin even if they are defined as autologin users. The setting PosConfigSetup.StaffAutoLoginFromWindows.ExcludeList is a comma or pipe seperated windows login names to skip auto login

A example use might be where there is a shared login account that you do not want used for autologin, even if it becomes linked to a staff member.

Technical Trivia

The teller timeout function starts recounting from zero when actions are performed in the POS. (scanning, adding items, searching). Some screens also reset the timer when any keystroke is entered. Mouse movement does not reset the timer as there are often small vibrations or unfelt earthquakes that cause the mouse to move ever so slightly.

If a Sync operation is in progress (for sites that use this) the timer is automatically extended while the sync is active.

When security is enabled, some advanced/rare functions in the POS might "double prompt" for login details even though the user is already logged in. This is solely for verification and auditing that the current user really is who we think, and not someone using anothers account. An example is where items are being deleted from a partially paid sale in order to bring the sale total below the amount paid. While a valid operation, it is also possibly indicating fraud