Skip to main content
In shops with an internal sales team or customer service, there are accounts with special rights, the so-called SuperUsers. A SuperUser searches the shop for a customer account and then logs in as that customer, for example to take an order over the phone or to trace a basket. The UL- tags build the result list of this search. They loop over the accounts found, output their address data and create the login link for each hit. Guide: SuperUser
All tags on this page belong on the template for the customer search. You build the search form itself with WS- tags and the result list with the tags on this page.
The search only runs for an account that is set up as a SuperUser. Without this flag, the shop system returns no hits at all, regardless of what is in the template.

​
The frame around the result list

The hits are not simply available but are retrieved via a pseudo category index. UserSearch is this index, and it is used exclusively within CAT-AdvData(), preceded by a dollar sign.
The number in the second argument of CAT-AdvData() limits how many hits the loop runs through. The previous documentation consistently shows 999 but does not say what the number stands for. A smaller number makes sense if you deliberately want to keep the list short.
Independently of this, the shop system already limits the number of hits in the database query. A very large number in CAT-AdvData() does not lift this limit. Advise the SuperUser in the template to narrow down the search instead of expecting a complete list.
UL-Data exists only as a loop. To check whether there are any hits at all, use the bracketing around CAT-AdvData($UserSearch,…) itself.
Reference: CAT-AdvData()

​
The details of the account found

Two tags return the identifiers of the account.
UL-Number and UL-Email are available in the shop system but are not described in the previous documentation. The customer number in particular is usually the most important column in the result list, because it distinguishes customers with the same name more reliably than the address.
Both tags also work as bracketing, namely when the value is filled. Not every account has a customer number.

​
The address data

You get all other details via the technical name of the respective address field, preceded by UL-.
The technical field names are listed in the AddressFields-Txt section of the shop configuration. Put UL- in front of one, and the field is available in the result list.
Only the fields of the billing address are available. The shop system matches the name against the field definition of the billing address, so fields that only exist for the delivery address find no counterpart. The previous documentation speaks generally of address data fields.
A typo in the field name is not reported as an invalid tag. The shop system simply finds no matching field and outputs an empty value. A bracketing around it then hides its content as well. So check the field name against the shop configuration if a column remains unexpectedly empty.
The address field tags also work as bracketing, namely when the field is filled. The previous documentation lists them only as single tags. For fields that not every customer fills in, for example the company or the second street line, the bracketing is the better way, because otherwise there are empty lines in the list.
Reference: AddressFields-Txt section in the shop configuration

​
Logging in as a customer

UL-LoginLink creates the link for each hit through which the SuperUser logs in as that customer.
UL-LoginLink is exclusively a single tag. The previous documentation lists it as a loop tag, which is obviously the specification of UL-Data copied over by mistake. The source’s own example uses it correctly as a single tag.
The link is an absolute address via HTTPS and switches the session to the selected customer account. Everything that happens in the shop afterwards happens under this account.
A restricted SuperUser may only log in to the accounts assigned to them. This check takes place in the shop system, not in the template. The result list therefore shows a restricted SuperUser only their own customers from the outset.
Clearly state in the template which customer the switch is made to. After the switch, the SuperUser sees the shop from the customer’s perspective, and without a corresponding notice in the template, the difference from a normal login cannot be recognized.

​
What can be searched for

The SuperUser determines the search type in the search form. The shop system knows these types:
With the search type Name, a comma separates last name and first name. The input Müller,Anna searches for both at once, the input Müller only for the last name. This is not stated in the previous documentation and is important for the usage instructions in the template.
All searches are partial matches. The input müll therefore also finds Müller, regardless of upper and lower case.
Deleted accounts do not appear in the result list. When searching by email address and customer number, accounts marked for deletion are skipped as well.

​
The tags of the search form

The form itself belongs to the WS- prefix and is described there. Reference: These five tags on the page WS- (General tags)

​
The tags at a glance

All tags apply on the template for the customer search and exclusively within the UL-Data loop. This loop in turn is located within CAT-AdvData($UserSearch,…).
  • Guide: SuperUser
  • Reference: CAT-AdvData()
  • Reference: WS- (General tags)
  • Reference: AddressFields-Txt section in the shop configuration