Skip to main content

How to Choose Which Customers a Sign-in Reaches

Every Customer portal sign-in is linked to one or more of your customer accounts, and the customer sees only those accounts' calls, visits and account details. You set this in the Customers section of a sign-in on the Customer sign-ins screen (menu, then Administration). There are three ways: pick the accounts one by one, give every customer, or write a Structured Query Language (SQL) filter that chooses a group.

Open the sign-in on the Customer sign-ins screen, choose Pick the accounts in the Customers section, and pick each account from the search box. Then press Save (or Create the sign-in for a new one).

  1. Open the sign-in with Open on the People tab, or press Add someone for a new one.
  2. Choose Pick the accounts under Customers.
  3. Type part of the account's code, name or address into the box that says "Search by code, name or address…", and choose the account from the list. Repeat for each account.
  4. Press Save at the foot of the Customer sign-ins form.

Each picked account appears as a small tag with its name. To take one off, press the × on its tag (its name is read out as "Remove" followed by the account's name).

A customer linked to one account goes straight to that account when they sign in. A customer linked to several first sees a list of their accounts and chooses one; this suits a head office that looks after several sites.

Until something is picked, the section says "Nobody is linked yet. A sign-in has to reach at least one account: blank would have meant every customer in the database, which is what the old portal did."

What do Every customer and An SQL filter mean?​

Every customer gives the sign-in every customer account in the database. The screen warns: "Every customer account in the database. Almost nobody outside the company should have this; a sign-in that reaches more than 2,000 accounts is refused at the door." In practice, a site with more than 2,000 customers cannot use it for anybody. On the People tab, a sign-in set to Every customer says Linked by an SQL filter, like one linked by a filter.

An SQL filter links the sign-in by a statement instead of a list. It is for accounts that belong together, such as a customer group: the filter picks whichever accounts are in the group at the time, so an account added to the group later is reached without anybody editing the sign-in. Most sign-ins brought over from the old web portal were linked this way, and their line on the People tab says Linked by an SQL filter.

To write one, choose An SQL filter and type the statement into the box under Advanced. The easiest way to start is to pick an account with Pick the accounts first, copy the statement that Advanced shows, then switch to An SQL filter and change only the part after WHERE. The note under Advanced gives the kind of group filter the old portal used.

Switching between the three choices does not lose your picked accounts: switch back to Pick the accounts and they are still there.

The People tab never runs a filter, so Linked by an SQL filter does not say which accounts a sign-in gets. To see them, open the sign-in on the Customer sign-ins screen and press Preview under Advanced: it shows how many accounts the sign-in reaches and lists the names and codes of up to 200 of them.

What does Advanced show, and how do I use Preview?​

Advanced, under the Customers section of a sign-in on the Customer sign-ins screen, shows the exact statement that will be stored for that sign-in, whichever of the three choices you made. It opens by itself when An SQL filter is chosen. With the other two choices the box is read-only, and it changes as you pick accounts.

Preview, under that box, runs the statement exactly as the customer's sign-in will run it and shows how many accounts it reaches, such as "2 accounts", followed by the names and codes of up to 200 of them. Use it before saving a filter, especially a group: it is the only way to see what the customer will get.

Preview can also answer with a message instead of a list:

  • "This filter cannot be run —" and a reason: the statement breaks one of the rules for customer filters. It must be a single SELECT that returns a column called UniqueId, with no semicolon anywhere, brackets that balance, and none of the words that change the database, such as UPDATE, DELETE, UNION or SET. The reason names the rule it broke.
  • "This filter reaches" a number of accounts, "more than the 2,000 one sign-in may hold. Narrow it, or nobody using it will be able to sign in."
  • "SQL Server would not run this filter:" followed by the database's own message, for example when the statement names a column your database does not have, or does not return a column called UniqueId. The filter passed the rules, and the database itself refused it.

A sign-in linked by a filter is never run just by opening it: only Preview runs it.

The Customer sign-ins screen has no way to open the Customer portal as a particular customer, so Preview is the nearest check of what they will see: it lists the accounts, and which of those accounts' calls the customer sees then depends on Call statuses they may see, Call types they may see and the date on the Defaults tab.

What rules does a customer filter have to follow?​

A customer filter on the Customer sign-ins screen must be a single SELECT statement that returns your customers' unique IDs in a column called UniqueId, in the same shape as the statement Advanced shows for picked accounts. ABM Service refuses a filter, with the reason, when:

  • it does not start with SELECT;
  • it contains a semicolon anywhere, even inside a quoted value, so it could be more than one statement;
  • it closes a bracket it never opened, or leaves one open;
  • it has an unclosed quote, square-bracketed name or comment;
  • it uses a word that changes or controls the database, such as INSERT, INTO, UPDATE, DELETE, DROP, EXEC, UNION, DECLARE or SET;
  • it contains the letters xp_ or sp_ anywhere outside a quoted value, even as part of a longer name, because those begin the names of system procedures.

Other words inside quoted values are allowed, so a filter looking for customers whose name contains one of those words is fine.

Saving checks these rules but does not run the filter, so a filter that breaks nothing can still reach too many accounts or fail when run, for example because it names a column your database does not have. Press Preview before Save. If a saved filter cannot be run, or reaches more than 2,000 accounts, the customer cannot sign in until you correct it. A filter that SQL Server itself refuses is the hardest to spot from the customer's side: they are told only that your database, named by its server and database names, "did not answer."

When does a change to a customer's accounts reach them?​

Saving a sign-in on the Customer sign-ins screen signs that customer out of the Customer portal at once, or within a minute if you are using the ABM Service desktop app. When they sign in again they see the accounts you chose.

The customer does not have to do anything: on their next click in the portal they are taken to the sign-in page, and they sign in again with the same password. Taking an account away works the same way, so a customer loses sight of an account's calls, visits and invoices as soon as you save.

A filter that picks a group is run again when the customer signs in, whenever they open their list of accounts, and at least once an hour while they stay signed in. So an account that joins the group appears for them within the hour, without anybody touching the sign-in. An account that leaves the group disappears for them on the same timetable.

If the filter stops working while they are signed in, for example because it was edited into something that cannot be run, the customer is signed out at that point rather than shown a half-empty portal.