Registration rules define automated actions that are executed when user data is stored in the imc Learning Suite. They are used to enrich user information, manage assignments such as groups, clients, certifications or job profiles, and grant access rights automatically on the basis of defined conditions.
All registration rule settings are maintained in the LMS. References to former file-based storage outside the application are no longer relevant for this functional description.
Registration rules are typically applied when a user profile is created or updated manually, when user data is processed by an import, or when user information is updated through connected interfaces.
Purpose and Use
Registration rules support the automation of recurring administrative logic. This reduces manual effort and helps ensure that user-related settings are applied consistently.
-
User attributes can be set automatically based on other attributes.
-
Users can be assigned automatically to organisational entities such as groups, clients, certifications or job profiles.
-
Clearances can be granted automatically to defined users, groups, clients, managers or owners.
The rules are processed sequentially in the order in which they are defined.
Where Registration Rules Are Managed
Registration rules are configured in the LMS. Depending on the scenario, they can be maintained in the configuration of imports and related administration areas within the system.
If user imports are used, registration rules can also be connected to the relevant import configuration so that the defined logic is applied during processing.
Structure of Registration Rules
A registration rule consists of four logical building blocks.
|
Building block |
Purpose |
|---|---|
|
Rule |
Defines one logical unit of processing. |
|
Condition |
Determines whether the commands of the rule are executed. |
|
Command |
Defines the action that is carried out if the condition resolves to true. |
|
Hashtable |
Provides value mapping for commands when an input value must be translated into an output value. |
Multiple rules can be defined. Each rule may contain one or more conditions and one or more commands. If value mapping is required, a hashtable can be referenced by the corresponding command.
Rule components are read in sequence. The order of definition is therefore relevant for the final result.
Execution Logic
Registration rules are executed whenever a user profile is stored. This includes the following typical events:
-
manual creation of a user
-
manual update of a user
-
import-based processing of user data
-
interface-based updates of user records
Because rules are executed on storage, the resulting behaviour should always be assessed together with the source and frequency of the relevant user updates.
Conditions
Conditions act as filters. A command is executed only if the condition of the rule resolves to true.
The following logical condition types are available:
-
andCondition – all included conditions must resolve to true
-
orCondition – at least one included condition must resolve to true
-
notCondition – the included condition must resolve to false
Each condition can use attributes such as the expression to be checked, the comparison operator, the comparison value, and where required the mode or list separator.
Different condition types cannot be nested arbitrarily within one another. If more complex logic is required, it should be split into multiple rules.
Comparison Operators
The available comparison operators determine how the expression is evaluated.
If an attribute is linked to a selection list, the comparison is made against the object ID rather than the displayed key.
Commands
Commands define which action is executed when the rule condition is fulfilled.
Set Command
The set command writes a value into an attribute. Both system attributes and custom attributes can be addressed.
-
language can be derived from country
-
main client can be set automatically
-
default values can be applied to users who meet defined conditions
Assign Command
The assign command creates assignments for the user. Depending on the context, this can include groups, clients, certifications or job profiles.
The execution mode is particularly relevant:
-
ONCE – assignment is executed once in a way comparable to a manual assignment
-
ALWAYS – assignment is treated as import-controlled and is re-applied during later executions
Extended assignment types can also be used for organisational relations such as supervisor or deputy, provided that the relevant scenario is configured accordingly.
Grant Command
The grant command defines which users or organisational entities receive clearances on the created or updated user.
Depending on the context, clearances can be granted to:
-
specific users
-
groups
-
clients
-
manager relations
-
owner relations
Clearance levels can be provided either through predefined keywords such as _view and _full or through decimal values where a more specific access definition is required.
Hashtables
Hashtables are used when one input value must be translated into another value before a command is executed.
Typical examples include the mapping of:
-
country to group ID
-
country to time zone
-
external source value to internal selection list ID
A hashtable contains an identifier, a default value and one or more mappings. The default value is applied whenever the input value does not match any defined row.
Hashtable Rows
Static mappings can be defined directly through rows. Each row contains one input value and one output value.
SQL-Based Hashtable Lookup
A hashtable can also retrieve its output value through a SQL statement. In this case, the command passes an input value to the hashtable, and the query returns one single result.
Only one placeholder is permitted in a SQL-based hashtable statement. The statement must return exactly one value.
If a hashtable is used, it must be defined before the rules that reference it.
Typical Use Cases
-
automatic assignment to a country-specific learner group
-
automatic setting of the main client if no client is provided
-
automatic assignment of a certification to users marked as relevant
-
automatic granting of view or edit rights based on organisational data
-
automatic assignment of supervisor-related group roles
Rules and Limitations
-
Rules are processed sequentially.
-
Conditions of different logical types cannot be nested freely.
-
Multiple negations should usually be modelled with an and-condition and UNEQUAL comparisons.
-
Selection-list-based checks use internal object IDs.
-
The behaviour of ONCE and ALWAYS should be chosen carefully, especially in import scenarios.
-
The default value of a hashtable is mandatory and should be defined with care.
For maintainable configurations, simple rules with clearly separated logic are generally preferable to highly condensed rule sets.
Practical Evaluation Considerations
Before a rule is activated in productive use, the following aspects should be verified:
-
which event stores the user and therefore triggers the rule
-
whether the source values are delivered in the expected format
-
whether referenced IDs exist in the target client or context
-
whether repeated execution should preserve or overwrite previous assignments
-
whether fallback values in hashtables lead to a valid result
Related Topics
-
Import configuration
-
User management
-
Groups and organisational structure
-
Clearances and rights management
-
Certifications and job profiles