In the IGA context, onboarding refers to ensuring that when an employment start date occurs, the user has all necessary credentials and access rights activated and delivered. This process begins when personal and employment-related information is added to the source system and delivered to the IGA solution, which then initiates the logic for work period management and directory account creation.

With the IGA Access Right Management (ARM) plus the User Lifecycle Management (ULM) package, birth rights can be granted automatically. However, if access rights are granted automatically based on users title, organizational unit or cost center the automated rule use case is required from the use case library. 

For more information on how and where a user's personal and employment information can be received, please refer to the chapter on Source System Options.

Update user information means that when user's employment or personal data is changed in the source system, the changes are updated also to users existing accounts, work periods and access rights. Also automatically granted access rights (automated rules) are updated based on received changes from the source system. 

Please check chapter “Source system options” for more information about how and where user's personal and employment information can be received from. 

The departing user use case refers to the process initiated when a user's employment or contract is ending. The IGA solution starts the offboarding process, which can take several days to complete, depending on the account management settings, such as when accounts are disabled, email licenses are removed, and access rights are revoked.

In cases where the user has multiple work periods, the offboarding process may only apply to the specific work period that is ending. This means that only the accounts and access rights (entitlements) related to that particular work period are terminated.

There are different administration tasks, which are depended on which settings IGA admin has selected for work period and account management. 

The Self-Service contains ready-made use cases for adding and updating users personal and employment related information. 

• Use cases for Self-Service can be found from here. 
   
• Self-Service can be used as a starting point for managers and end-users to start on- and offboarding and make changes to internal and/or external users' personal and employment related information. 
   
• Self-Service can also be an alternative option, meaning that, for example, internal user information is received from the customer's HR solution, while external user information is added via Self-Service.

Native HR connector is recommended to be used every time file-based integration is needed or it covers the integration requirements. It is build by using custom script connector, and it can be modified according to customer needs. It also allows customer to define different limits like for example how much changes is allowed per import etc. 

Read more about native HR connector from here. 
Read more about custom script connector from here.  

Benefits for native HR connector:

• Supports CSV, XML and JSON files.
• Can receive and send files to/from SFTP-server (recommended) or other file locations.
• Parameters, connection details, limits etc. are configured from IGA solution. 
• Script can be customized (changes requires Python scripting skills, but can be done by customer, Efecte or Partners).

When to choose another option for HR integration?

• When other than file-based integration is required.
• In case where heavy customization and/or logic is needed in the integration, like for example combining information from several source systems.
• Customer or partner wants to build and maintain integrations by themselves (Open API).
• Customer wants integrations as a service (Efecte Integration Service). 

Integration Service is used in complex and customized integrations, these can, for example, be database or direct integrations to different HR solutions.

We recommend to use Integration Service or customer's own integration platform in cases when:

1. Personal and employment related data is received from several source systems and data needs combining before it can be delivered to IGA solution.
2. Real-time integration between IGA solution and source system(s).
3. Complex and customized integrations.

Read more about Integration Service from here. 

Open API is for cases where customer or partner is managing their integrations by themselves, or another integration platform than Integration Service is used. 

We recommend to use Open API when:

1. Customer builds their own integrations.
2. Real-time integration is required between IGA solution and source system(s).
3. Complex and customized integrations.

Read more about Open API from here. 

Here you can find terminology for user lifecycle management, but don't forget to also check The Glossary. 

Work period management and account management are distinct processes. In work period management, we define how received information is handled, while in account management, we determine what information is delivered to directories. Attribute mappings specify whether the received data needs to be combined or transformed before it is delivered to the directories.

IGA solution supports four (4) scenarios for work period and account management, which means that users can have one or more work periods and accounts, which all are related to one identity. 

One work period and one account

This scenario is most common one and can also be first step towards more complex user lifecycle management. 

In this scenario, user has one work period and there is one account related to the work period, which means that users access rights and account activation / de-activation are done according to employment start and end dates, which are defined for the work period. 

Settings in IGA set work period data card: 

• Status - Active.
• Name - Give a name for your work period management rule.
• User type - Select correct who this setting is applying.
• Target directory - select one (1) directory from the list, where user account is created (in the following step you will need to match this information for account management).
• Amount of work periods - in this scenario, it is always one (1).
• Account handling - is selected to be "attach one account to all types of work periods.
• Save information.
• Create equivalent IGA set account information data card with the user type selected in IGA set work period data card.

One work period and several accounts

This scenario allows users to have multiple accounts (in one or different directories), which are all related to one work period, which is then related to one identity. 

This scenario applies also in cases, where user has normal and privilege (for example domain admin) accounts in same directory, and those are related to one work period. In case the work period is ending, both accounts will be disabled/removed according to work periods end date and settings in account management. When creating several accounts it can happen simultaneously, which means that both will be activated according to work period start date or one of the accounts can be created before/after another like for example based on access right request made from Self-Service. In update cases, information in both accounts are updated/changed, and new directory attributes are calculated based on account management settings. 

In cases where user has several accounts, primary account is mandatory to be calculated, especially if user needs to access and use services in Self-Service or in IGA solution. 

Settings in IGA set work period data card: 

• Status - Active.
• Name - Give a name for your work period management rule.
• User type - Select correct who this setting is applying.
• Target directory - select two (2) or more directories from the list, where user accounts are created (in the following step you will need to match this information for account management).
• Amount of work periods - in this scenario, it is always one (1).
• Account handling - is selected.
  • Attach one account to all types of work periods means that user has only one account and that same account will be attached to user's all work periods regardless the employment type.
  • Create new account matching employment type means that if user already has an account, but the employment type is different on a new work period, another account will be created. However, if the user already has an account that is matching the employment type, that account will be attached to the new work period.
• Save information.
• Create equivalent IGA set account information data card with the user type selected in IGA set work period data card.

Several work periods and one account

In this scenario user can have several work periods related to one directory account, and with this, users access rights (entitlements) can relate to any of the work periods. 

When work periods are added/removed to/from the user, access rights are always relating to one of the work periods, which means that in cases where one of the work periods is ending and user has same access right (entitlement) given through another work period, it won't be removed until all work periods granting the access rights are ended, or automated rules are updating access rights. Departing user process is started when none of the work periods are no longer active.

In this case, it is mandatory to calculate primary work period for the user, for which personal information is used as identity information for the user. This case also has effect to Self-Service, which means that it is mandatory to select work period when requesting/removing access rights from the user. This also brings possibility to add/end work periods for the user, using on-boarding/update/off-boarding services in Self-Service. 

Settings in IGA set work period data card: 

• Status - Active.
• Name - Give a name for your work period management rule.
• User type - Select correct who this setting is applying.
• Target directory - select one (1) directory from the list, where user account is created (in the following step you will need to match this information for account management).
• Amount of work periods - in this scenario, it is always multiple.
  • First priority employment nature - permanent/temporary/hour-based.
  • Second priority employment nature - temporary/hour-based.
  • Third priority employment nature - temporary/hour-based.
• Account handling - is selected.
  • Attach one account to all types of work periods means that user has only one account and that same account will be attached to user's all work periods regardless the employment type.
  • Create new account matching employment type means that if user already has an account, but the employment type is different on a new work period, another account will be created. However, if the user already has an account that is matching the employment type, that account will be attached to the new work period.
• Save information
• Create equivalent IGA set account information data card with the user type selected in IGA set work period data card.

Several work periods and several accounts

This is the most complex scenario for user lifecycle management, and it allows user to have several work periods and accounts. 

In this case it is mandatory to calculate both primary account and work period for the user, and it combines all scenarios into one. 

Use case example: in education sector, user is teacher during office working hours and in the evenings also a student. It is common that students and teachers are located in totally different directories, and some might be located in on-premise and/or cloud directories. This scenario is also common in health care and other sectors where user might be working in different roles under different contracts. 

Settings in IGA set work period data card: 

• Status - Active.
• Name - Give a name for your work period management rule.
• User type - Select correct who this setting is applying.
• Target directory - select two (2) or more directories from the list, where user accounts are created (in the following step you will need to match this information for account management).
• Amount of work periods - in this scenario, it is always multiple.
  • First priority employment nature - permanent/temporary/hour-based.
  • Second priority employment nature - temporary/hour-based.
  • Third priority employment nature - temporary/hour-based.
• Account handling - is selected.
  • Attach one account to all types of work periods means that user has only one account and that same account will be attached to user's all work periods regardless the employment type.
  • Create new account matching employment type means that if user already has an account, but the employment type is different on a new work period, another account will be created. However, if the user already has an account that is matching the employment type, that account will be attached to the new work period.
• Save information.
• Create equivalent IGA set account information data card with the user type selected in IGA set work period data card.

One work period and one account (for access right management, when user lifecycle management is not used)

This is most lightweight process to manage work periods and accounts in IGA solution, and this scenario is meant for those cases where account related data is only read from the directory and used as identity and person information (IGA Access Right Management package). 

It is important to generate work period data, even if IGA solution is not creating/updating/removing accounts and identities automatically, since access rights and accounts always needs to based on some kind of contract or agreement between user and the company/organization. in case where automation for user lifecycle management is added afterwards to customer's IGA solution, there is no need to make any configuration changes, only decide where personal and employment related information is received. 

There is no need for any settings in IGA set work period or IGA set account information data cards.  

Account management

IGA admin can define different type of rules how directory accounts are created/updated/removed, which type of birth rights are granted, which attributes from the work period is used to generate directory attributes like for example email address etc.

Read more information about account management from here. 

Primary work period calculation

IGA admin can define calculation for primary work period in work period management settings and use three (3) pre-defined employment nature type's for the calculation. 

Priority 1: Permanent, hour-based, temporary

Priority 2 & 3: Hour-based, temporary

When work periods are received and work period bundle is created, workflow will first validate based on priorities and if user has same type of work periods (like for example two (2) temporary work periods), the one which has started first is marked as primary work period.  

Primary account calculation

Read more about primary account calculation from account management use case.

User type

Both user type and employment type can be received from source systems, and both have different meaning and function. User type describes if user is employee, guest, external etc. type of user. Employment type describes if, for example, the employee user type has permanent or temporary type of employment contract. 

User type is linked to account management, meaning that same selected type in work period management (IGA set work period) needs to have equivalent type of account management (IGA set account information) rules.

Pre-defined user types are:

• Employee
• External admin user
• External consultant
• External project manager
• Guest
• Internal
• Other
• Privileged
• Trainee

Attribute mappings

Define attribute mappings between source - IGA solution - directory / application, it is important to know if attributes are matching perfectly or is some logic required to for example combine information 

Below you can find example how attribute mappings are defined, during the IGA delivery we will provide full list of pre-defined / mandatory / optional etc. attributes based on work- and account management requirements. It is important to always consider also if the attribute from source system can be used as it is or does it require some logic to be added before IGA solution delivers the information to the directory. 

User lifecycle management contains several data cards, which all have their own purpose in the processes and for auditing reasons. 

Receiving information: 

• Information from HR solution is received to IGA work period data card(s) and IGA service request data card is generated for provisioning.
• Information from Self-Service is received to IGA service request data cards and IGA work period data card(s) are generated for work period management.
• Information from directory is received to IGA account data card and work periods are generated for access right relations.
• If user has active work period with same information, IGA solution moves to either update user information or departing user workflows.
• IGA solution validates from IGA set work period data cards, the rules work period management and generates IGA work period bundle data card for the user.

IGA work period is used for:

• Collecting individual work period & personal information related to the user into one data card.
• Users access rights (entitlements) and accounts are related to users work period(s), which means that each work period can have different start and end date, and all users related access rights and accounts are activated / deactivated based on the relation to the work period.
• In cases where user can have multiple work periods, information related to users primary work period & account are used for generating person and identity storage data cards
• Person data card is generated for the user based on primary work period information
• Identity storage data card is generated for the user based on primary work period information

IGA set work period is used for:

• IGA admin to be able easily define rules for receiving information related to different type of work period information for different user types.
• Defining how many directory accounts are created for selected user type.
• Defining if the rule is used as primary rule in cases users can have multiple work periods.
• Defining how many work periods can related to the user.
• Defining primary account calculation priorities.
• Generating IGA work period bundle data card.

IGA work period bundle is used for:

• Collecting all work period(s) and personal information related to the user into one data card.
• Calculating users primary work period, based on definitions made in IGA set work period data cards.
• In case primary work period cannot be calculated, IGA admin task is created and primary work period selection is made manually by IGA admin from the users active work period bundle data card.
• IGA service requests are generated for provisioning.

IGA service request is used for:

• Starting initial user creation or update workflow.
• Collecting all information for new user account provisioning to the directory/directories:
  • From IGA set account information data card IGA solution validates rules for generating attributes for the directory account(s), which are created for the user. 
  • From related work period data card(s) IGA solution validates users attributes, which are used for generating attributes according to defined rules in the IGA set account information data card(s).
• IGA admins to follow up and monitor user creation.
• IGA admins to cancel requests or approve them to continue to provisioning, if workflow is stopped for admin review before provisioning.

IGA account is used for:

• Receiving user account information from directory/directories.
• Each directory account will have its own IGA account data card.
• In cases where user can have multiple accounts, IGA admin can manually change primary account information from IGA account data card.
• IGA admins to view access right (entitlement) and account relations.

IGA set account information is used for account management:

• IGA admin to be able easily define rules for writing user account information related to different directories.
• Defining settings for generating attributes for the directory account creation (example: what kind of email address(es) are generated for the user).
• Defining birth rights, which are given to the user once (only when the account is created) (attribute-, role-, and organizational-based rules are managed with automated rules).
• Communication to stakeholders about new user creation, update or departing user.
• Password policy, and how first time password is delivered.
• Departing user settings like for example when access rights (entitlements) are removed, when the account is disabled, etc.

Person is used for:

• After person data card has been created for users, it is possible to allocate accesses for end-users to be able to access Self-Service and admin users to be able to access IGA solution. 
• Information visible in Person data card is coming from users primary account and work period data cards. 
• IGA admins to view all active users and their directory account(s).
• Primary account calculation is made in Person data card.

IGA identity storage is used for:

• Collecting all information related to the users access rights, work period(s) and responsibilities inside of IGA solution such as owner or approver responsibilities.
• Holistic view for IGA admins to review all relations and information related to one user.

IGA access right record is used for:

• Storing auditing information.

IGA admin task is used for:

• Informing IGA admin if primary work period calculation is not successful.
• Informing IGA admin if any issues with provisioning or native HR connector.
• Informing IGA admin about name sake reviews.

Here you can find customer instructions for how to get ready for user lifecycle management, what to prepare for upcoming changes and where to find information for maintaining and supporting IGA solution. 

Link here. 

Relations to other use cases,

• ​Request access rights - can be added to on-boarding use case, and in case user has multiple work periods, end-user needs to select correct work period for the user in Self-Service, when requesting access rights. 
• Remove access rights - can be added to off-boarding use case, and in case user has multiple work periods, end-user needs to select correct work period for the user in Self-Service, when removing access rights. 
• Self-Service: Create new user - service in Self-Service which is used as a starting point for new users.
• Self-Service: Update user information - service in Self-Service which is used as a starting point for updating user information or for departing users. 
• Manage automated rules - for granting access rights (entitlements) and business roles automatically based on roles-, attributes,- and organizations.

Defining user lifecycle management

Requires workshops together with customer, where, at minimum, the following steps are documented and agreed with customer. Check from your delivery team how many workshops are needed, and are all documents needed for your customer case. 

1. Use case descriptions.
2. Source system description (not needed if only Self-Service is used), prod & test.
3. Directory descriptions, prod & test.
4. Attribute mappings.
5. IGA set work period data cards (not a document, done in IGA solution).
6. IGA set account information data cards (not a document, done in IGA solution).

Configuration instructions

These configuration instructions are related to other instructions, so please make sure that you follow up correct ones.

1. Configure directory connector and test connection.
   • Please follow up directory specific connector descriptions.
   • Connector tasks are configured later on.
      
2. Configure source system integration
   • In case Self-Service is used for receiving personal and employment related information, please check also configuration instructions for Self-Service: create, update user & departing user information use case. 
   •  If native HR connector is used, please check HR connector description. 
   • When Efecte Integration Service or Open API are used, configuration instructions varies a lot for the integration, but for provisioning, account- and work period management, please follow up these instructions. 
      
3. Create IGA set work period data cards according to user types
   • Check settings from “account & work period management” chapter above. 
      
4. Create matching IGA set account information data cards (matching with user types used in IGA set work period data cards) 
   • Check settings from account management
      
5. Publish workflows from IGA service request template
   • 1.0 Create or update user initial workflow
   • The directory workflows that the customer is using 
     • Named as: 1.x [Directory] - Create or Update User
        
6. Configure directory connector (Provisioning Engine from version 2024.2 upwards)
   • Open correct connector for the directory from the list and test that connection and authentication are working.
   • Select following event-based tasks and configure/change information for the tasks
     • [Directory] IGA Service request: Activate account
     • [Directory] IGA Service request: Create user
     • [Directory] IGA Service request: Read user
     • [Directory] Update Organizational information
     • [Directory] Update Personal information
     • [Directory] IGA Service request: Verify user
     • Azure IGA Service request: Set Manager
     • [Directory] AD IGA Access Right Record: Remove or Add Group
        
7. Configure EPE tasks (Provisioning Engine version older than 2024.2)
   • Select following event-based tasks and configure/change information for the tasks including connection details for each task.
     • [Directory] IGA Service request: Activate account
     • [Directory] IGA Service request: Create user
     • [Directory] IGA Service request: Read user
     • [Directory] Update Organizational information
     • [Directory] Update Personal information
     • [Directory] IGA Service request: Verify user
     • Azure IGA Service request: Set Manager
     • [Directory] AD IGA Access Right Record: Remove or Add Group
        

Configure additional directory

1. Add new directory option to following attributes,
   • Template: IGA set work period information
     • Attribute: Target directory/directories
   • Template: IGA set account information
     • Attribute: Target system
   • Template: IGA service request
     • Attribute: Target system
   • Template: IGA account
     • Attribute: Directory/application
   • Template: IGA entitlement
     • Attribute: Directory
2. Configure new connector (Provisioning Engine from version 2024.2 upwards)
   • Copy correct connector and all related tasks
   • Configure connection details according to the directory
   • Select following event-based tasks and configure/change information for the tasks
     • [Directory] IGA Service request: Activate account
     • [Directory] IGA Service request: Create user
     • [Directory] IGA Service request: Read user
     • [Directory] Update Organizational information
     • [Directory] Update Personal information
     • [Directory] IGA Service request: Verify user
     • Azure IGA Service request: Set Manager
     • [Directory] AD IGA Access Right Record: Remove or Add Group
        
3. Copy workflow for the correct directory from IGA service request workflows
   • Select workflow (named as: 1.x [Directory] - Create or Update User) from IGA service request workflows
   • Configure orchestration nodes to match new connector settings

Add or change user types

1. In IGA solution add / change value to following templates
   • IGA Set Work Period
   • IGA Set Account Information
   • IGA Service Request
   • IGA Work Period
   • IGA Account
   • Person
   • IGA Identity Storage
2. In Self-Service add / change value to
   • Create new users (onboarding)
   • Update user information (including departing users)

Testing user lifecycle management is depended on where information is received and are there any extensions to made to configuration. 

When IGA solution is delivered, Delivery Management tool is used also for system- and approval-testing (if not agreed otherwise), this means that there are ready-made test cases and tasks for both consultants and for customer. 

Preparing test data and test users

Before any testing can be started, following test data and test users should be created for testing purposes. 

• Below is the minimum set of test data and users
• Review the covered test scenarios and add more if needed
  • Include more test data and test users according to new test scenarios
• Review the test data, and update it according to the organizations data

Covered test scenarios with the following data,

Organizational data

Cost Center

Title

Users

Special cases:

• Special characters included → Jörg Mäkelä, André Dupont, Sophia Martínez, Isabella García
• Two users with same name → Anna Virtanen
• U013 and U014 share same information

Manager relations

Work periods

Special cases

• Past employment → U011
• Future employment start → U012
• Multiple work periods → U013
   

IGA roles

User and IGA role relations

Directory groups

 Application

What type of users the test data should contain?

• Internal and external users.
• Users with name containing special characters in their names (Ä, Ö, e´, etc.).
• Users with different type of work periods (permanent, temporary, external etc.).
• Users with several different type of work periods and directory accounts (not valid if customer has one work period related to one account).
• Users with same information than one of the existing users.
• Users with same name.
• Users who's employment end date is in the past.
• Users who's employment start date is in the future.
• Managers and subordinates.

Testing users created/updated/departed from Self-Service

1. Login to Self-Service with one of the manager type of test users:
   • Create new internal and external users.
   • Update existing subordinate information.
   • Update personal information (first name, last name etc.).
   • Update employment information (title, cost center, organizational unit).
   • Create new work period for existing user (not valid if user has one work period and one directory account).
   • Off-board existing subordinate.
   • Validate that Self-Service is showing request status correctly in the front page.
   • Validate that request history is showing information correctly in Self-Service.

Testing users created/updated/departed using native HR connector

1. Create a test file containing only new users:
   • 10 → xxx new users.
   • Run HR connector manually.
   • Validate that users are created correctly.
     • Check data card flow for validating all data cards.
   • Create a test finding in case there are issues, and fix preventing and critical findings before continuing.
2. Create another test file:
   • 10 → xxx new users.
   • 5 → xxx user updates to previously created users.
   • 5 → xxx departing users (previously created users).
   • Run HR connector manually.
   • Validate that users are created/updated correctly.
     • Check data card flow for validating all data cards.
   • Validate that departing user process is started/finalized, notice that this might take days to be validated (depending when end date occurs).
   • Create a test finding in case there are issues and fix, re-test and close preventing and critical findings.

Testing with Efecte Integration Service or Open API

1. Create test users straight to the source system.
   • 10 → xxx new users.
   • Run integration manually or test first with couple users. 
   • Validate that users are created correctly.
     • Check data card flow for validating all data cards.
   • Create a test finding in case there are issues, and fix preventing and critical findings before continuing.
2. Make changes to existing users.
   • 5 → xxx updates to existing users.
   • 5 -→ xxx departing users.
   • Run integration manually or test first with couple users.
   • Validate that users are created correctly.
     • Check data card flow for validating all data cards.
   • Create a test finding in case there are issues, and fix preventing and critical findings before continuing.