Identity Groups

An identity group is at its core a grouping of customers and may consist of any customer including guests. Each group can apply rules to the customers matched within, controlling the price group, discounts, loyalty points, access rights and fixed members. You can access identity groups via the Aurora admin menu.

Create a New Identity Group

Navigating to the Add Identity Group tab you will initially create an identity group providing only its name.

After doing so you will be presented with the edit page for your newly created Identity group where you can configure it to your needs.

Managing Identity Groups

Priority

Identity groups have conditions that when required are resolved against the user's request. This resolution process may result in zero or more identity groups as a result but a single identity group will need to be selected. To handle this Identity Groups have a "priority" field, which is a numerical value where the lower the number the higher the priority.

Price Group

When editing an Identity group you will may notice the Price Group field. This field allows for assigning a given Price group to an Identity group to be used within price group resolution.

1470

This allows for providing members of an Identity group different prices than that of another group or the default price group.

📘

The price group field will only show when multiple price groups have been enabled. Contact Aurora to action this on your behalf.

Priority

The priority is used to order identity groups when the identity group is selected i.e. which identity group to select first when a user has multiple identity groups assigned.
The lower the number the higher the priority. Leaving this field empty is the lowest priority.

Merchandising

Discounts and Loyalty Points can be applied to customers matched to a given Identity group. To understand how these are configured and how they work with the wider merchandising platform see our User and Group Discounts guide and Loyalty Points guide.

Members and Access Rights

An identity group can have dynamically assigned members or fixed members. Having fine-grained control over specific user access rights is helpful for individual roles however at times when more than a single user is in a role it’s beneficial to be able to enforce access rights to a group of users. This can be easily done with Identity Groups and fixed members. To understand more about how this is configured please see our User Access Rights guide

Conditions

Members can be dynamically assigned to an identity group for a request. How this assignment happens depends largely on the conditions an administrator creates within the conditions UI.

The UI allows for creating nested AND/OR based rules covering:

Constraints Key:

  • eq: equal
  • ne: not equal
  • gt: greater than
  • gte: greater than or equal
  • lt: less than
  • lte: less than or equal
  • in: matches a value from a list

Rule

Constraints (see key above)

Notes

Group: Customer

Has User Account

eq:yes/no

Is the current user logged into Aurora?
OR
API Identity Group requests that submit a user email address in the context match to a user account.

Group: Eagle Eye

This group is not available by default, talk to your AC account manager if this group of rules are required.

Has Valid Wallet

eq:yes/no

One of the following to be true to equate to “yes”:

Does the user have a valid discount card in their basket?

Does the user have an active Eagle Eye session with a valid Eagle Eye card.

If no active session does the user have an associated wallet id associated to their user account and do they have a valid Eagle Eye card

If an Identity Group API call, does it contain a user_email context item, and does the value match a user with a valid wallet?

If an Identity Group API call, does it contain a eagle_eye_discount_card context item, and does the value validate?

Group: API

Is an API Call

eq:yes/no

Is the current request an API request?

API V1 User

eq:Create

The request is from the selected V1 API user

API V2 User

eq:Create

The request is from the selected V2 API user

API Custom FieldIdent

eq:Create
ne:Identit
gt:p

Navi
gte:to the
lt:Identit
lte:** tab
in:ll ini
lly c:exists
entit:does not exist

A Condition Context Field provided in the Identity Group API Call will be matched (according to the constraint type) against a user-defined value.

k:ima is a string.
: [ is a string.
: [ is a comma-separated list of /ff08bds

Group: Locale

URL Slug

eq:Create
in:Identi

Does the current user's locale match the user-defined value?

roup** is a string.
tially is a comma-separated list of iding os

Group: Customer Order History

Order Count

eq:Create
gt:Identit
gte:

Navig
lt:to the
lte:dentity

The current logged-in customer's total number of orders is over/under the user-defined value.

ate an is an integer

Total Value

eq:Create
gt:Identit
gte:

Navig
lt:to the
lte:dentity

The current logged-in customer has a total historic order value over/under or equal to the user-defined value?

roup pr is a decimal or integer

Last Ordered Date

eq:Create
gt:Identit
gte:

Navig
lt:to the
lte:dentity

The current logged-in customer's last order was placed before/after the user-defined date.

create is a string with date format dd/mm/yy

Note during API requests Aurora will action all rules on the customer if a user email is provided (context key user_email) and a customer exists with that email. E.g the logged in rule will consider this truthy.

📘

Can't find a rule you need, let us know!