Overview
The Workday User Provisioning integration is for organisations using Workday as their Human Capital Management system.
The integration allows an organisation to initially import all active users or a subset of active users (based on some filters provided) from their Workday tenant into their Blink organisation. This is called the “initial sync”.
Once the initial sync has run, the integration will automatically monitor user profile changes, joiners and leavers in the Workday Tenant and reflect those changes on the Blink users: updating existing user profiles, creating new profiles for joiners and deactivating existing profiles for leavers.
This seamless synchronisation ensures that the Blink user base is always up-to-date with the latest information from Workday.
Architecture
This is an outbound integration from Workday to Blink only, meaning that Blink will only be pulling data from Workday and not updating any data in Workday.
This integration is solely running on the Blink backend at present, there is no user interaction in the Blink application.
There are 3 main processes the integration can run: Initial Sync, Delta Sync and Resync.
Initial Sync
After the integration has been set up (see section 2), the Blink Team will trigger the “initial sync” from Workday to Blink on the backend. During the “initial sync”, all or a subset of active users from your Workday tenant (inactive users will not be imported) will be brought into your Blink organisation.
To target a subset of users, the integration leverages the built in filters the Workday API offers:
Exclude Contingent Workers = only users of type “employee” in Workday will be imported in Blink
Exclude Employees = only users of type “employee” in Workday will be imported in Blink
Organisations = only users part of the list of Workday Organisations provided will be imported in Blink.
Countries = only users part of the list of Countries provided will be imported in Blink
If you have manually managed users in your Blink organisation prior to switching the Workday integration on, if they have employee ids or emails matching those in Workday, the integration will convert the existing Blink profiles into Workday managed ones and override existing profile information in Blink by the Workday data. Otherwise, a new profile will be created and will be managed by Workday.
If you do not have existing users in Blink, Workday will create brand new profiles for all users imported from your Workday tenant.
Delta Sync
Once the “initial sync” runs, the integration will automatically query the Workday data of your tenant every 5 minutes to check if any changes happened since the last check.
Changes detected are:
Update on an existing user: the integration will update the linked Blink profile with the latest profile information from Workday
New joiners: the integration will create a new Blink profile with the new joiner’s profile information from Workday
Leavers: the integration will deactivate the linked Blink profile
Rescinded Users: depending on when the user has been marked as rescinded in Workday, the integration will deal with it in different ways:
If the user has been rescinded in Workday before the integration picked up the user as a new joiner, then a Blink user profile will not be created at all
If the user has been rescinded in Workday after the integration picked up the user as a new joiner, this means the integration would have initially created a Blink user profile for that user. In that case, that linked Blink user profile will be deactivated.
💡 An additional check happens every day at midnight in your local time. It ensures at the start of the day that all changes effective on that day that have already been entered in the Workday tenant are reflected in Blink. Once this has run, the usual “Delta Sync” process resumes and ongoing changes are checked every 5 minutes.
Resync
This process can be run ad-hoc at the your request by the Blink Team, generally when a change of mapping or filter is required and need to be reflected on all user profiles in Blink.
A resync follows the same process as the “initial sync” - it will bring into Blink only all active or a subset of active users if filters are provided.
The difference with the “initial sync” is that if as a result of the sync, some users do not fall in the targeted audience anymore, they will be deactivated in Blink. New users captured will be added to Blink and existing users will be updated in Blink.
Configuration
Prerequisites
An active Workday tenant and an active Blink Organisation (required)
Using Workday as Human Capital Management System (required)
If you already have users manually managed in Blink, Employee IDs in Blink must match Employee IDs in Workday for a seamless transition. This will ensure existing profiles are taken over by Workday and current users can keep their existing account (required)
Workday Tenant Configuration (done by customer)
Create an Integration System User (required)
Create an Integration System Security Group (required)
Configure Security for the Integration System Security Group (required)
Create a Core Connector: Worker Integration System if the customer wishes to bring non standard Workday user fields into Blink (optional)
See step by step guide in sections 5 and 6 to carry out the above in your Workday tenant.
Configuration in Blink (done by Blink)
Once the configuration in Workday is done (Section "Workday Tenant Configuration (done by customer)") Blink will need the below information from you to be able to finalise the integration setup:
wsdl (required) = URL of the Human_Resources SOAP Web Service in the customer’s Workday tenant
username (required) = username of the Integration System User created in Section 2.2. It allows Blink to access your Workday tenant via the Workday API
password (required) = password of the Integration System User created in Section 2.2. It allows Blink to access your Workday tenant via the Workday API
timezone (required) = this determines when the daily update check is done (see Section 1.1.2.)
integration system id (optional) = the system id of the Core Connector: Worker Integration System created in Section 2.2 in the case non standards user profile fields need to be retrieved from Workday
mappings (required) = a correspondence between Workday user profile fields and Blink profile fields, guiding the integration on how to transfer data from Workday to Blink. Please see Blink fields available in the Appendices section.
Any Workday fields available on the Human_Resources Workday Web Service are usable by the integration, please see some common fields in the Appendices section.
Non standard fields can potentially be retrieved too when a core connector has been set up in (see sections 2.2. and 6)filters (optional) = options available are:
Exclude all contingent workers
Exclude all employees
Include only users part of one or several Workday Organisations (.i.e. Supervisory, Company, Cost Center) or Countries.
In the case of organisation or country filters, any Workday user not belonging to those groups will not be brought into Blink.
For organisation filters, we would need a Workday Organization_Reference_ID for each Workday organisation to be able to apply the filtering
For country filters, we need for each country the ISO_3166-1_Alpha-2_Code (ex: US, UK, FR)
By default all active users within the tenant will be synced over if not filters are provided
Dry Sync Run
Prior to running the “Initial Sync”, the Blink Team will run a “dry sync” which extracts the Workday data according to the mappings and filters you chose onto an excel spreadsheet without syncing any data into Blink yet.
Once the spreadsheet is extracted, the Blink Team will flag potential data issues that need addressing by the customer before the initial sync can be safely run. Those issues can be:
Duplicate external ID, username, mobile phone, email, employee ID
Missing external ID, username, mobile phone or email (if chosen to sync them into Blink as this would mean there will be no way for a user to sign up)
Blink will ask you to confirm the mappings chosen are to your satisfaction. User profile information is key to other functionalities in Blink such as Dynamic Teams, therefore the choice of mapping can be crucial.
Once the issues are resolved and you confirm you are happy to go ahead with the sync, Blink will run the initial sync.
Watch-outs & limitations
Versions v42.0 and v42.1 of the Workday SOAP API (Human Services Web Services and Get_Workers operation) are not compatible with our integration - versions prior v42.0 and post v42.1 are working as expected.
Workday Fields: if in doubt whether a field is available for the integration to use, please reach out to Blink. With access to the customer’s Workday Tenant, we can validate whether it is the case or not.
Organisation and Country filters in the Workday API can only be used to explicitly include groups in the sync. There is no out of the box Workday API solution to specify groups to exclude. Therefore to exclude a couple of groups, all groups needed to be included need to be specified, leaving out the groups to exclude. If you wish to exclude certain groups, we have a workaround for which we need a list of Organization_Reference_ID and names for all the Workday Organisations to exclude so we can reflect an exclusion rule on our side
When a sync runs, subsequent syncs do not. This is to avoid sync to clash and guarantee order of event processing. Although the integration checks for updates in Workday every 5 minutes, if a previous update is still being processed, there might be delays in seeing changes reflected in Blink
The Workday integration calculates if a user should be active in Blink following the below rules:
User is marked as “active” true and “terminated” false in Workday = active in Blink
User is marked as “active” false and “terminated” true in Workday = deactivated in Blink
User is marked as “active” false and “rescinded” true in Workday = deactivated in Blink
User is marked with any other combinations = ignored in Blink, will not be processed by the integration
Typically a Blink User managed by the Workday Integration will see all their profile fields locked and uneditable under the principle Workday is the unique source of data. Mobile and email function differently:
If you chose to map email or mobile from Workday and if there is data in Workday for those fields for a particular user, the data will be brought into Blink and mobile and email will be locked
If there is no data coming from Workday for those two fields, either because you did not choose to map them or because there is no data for those fields on a particular user:
If the user is new to Blink, the profile will be created with all fields locked except for mobile/email which will appear blank and manually editable, allowing an Admin to enter credentials for the user to be invited and log in
If the user already exists in Blink and is currently manually managed, the user will be taken over by the Workday integration, all fields will be overwritten by Workday data and locked except for mobile/email which will remain as they currently are and manually editable
If the user already exists in Blink and is already managed by the Workday integration, if they currently have mobile/email previously synced and locked by Workday, those would be blanked and become manually editable. On the opposite if they currently have manual mobile/email in Blink (editable), those will stay as they currently are.
Frequently Asked Questions
How are the integration system user credentials stored?
How are the integration system user credentials stored?
They are encrypted and stored in our database.
What Workday user data do you access and store?
What Workday user data do you access and store?
We access all data returned by the Get_Workers SOAP Web Service Form Workday within the limit of the permission set at the time of configuring the integration in Workday. We only use the Workday profile fields specified by the customer in the mappings submitted. The data is stored in our database with all user profiles for the customer’s organisation so it can be visible in Blink. Any other Workday data is discarded.
What access permissions are required by the integration to get the Workday data?
What access permissions are required by the integration to get the Workday data?
The Integration System User for the our Workday integration requires to belong to a security group with READ access only to the following Domain Security Policies: “Worker Data: Public Worker Reports” and “Worker Data: Current Staffing Information”. You also have the option at configuration time in your Workday tenant to constrain the Security Group the Integration System User belongs to specific organisations, meaning only data from users belonging to those organisations will be fetched by Blink via the Workday API.
What happens to a user profile in Blink when managed by the Workday integration?
What happens to a user profile in Blink when managed by the Workday integration?
On the user profile page, you will see mentioned the user is managed by an external source and all profile fields will be locked and uneditable manually to preserve Workday as the unique source of data. Mobile and email function differently, see “What happens if I do not wish to sync mobile or email?”.
What happens if I do not wish to sync mobile or email?
What happens if I do not wish to sync mobile or email?
Please refer to the "Watch-outs & Limitations" section for impact of a user profile. The other aspect to consider is login. Mobile or email are the main source of login at Blink. Not syncing those through Workday would mean for an Administrator to manually add contact details for new joiners so that they can be invited to Blink.
Workday Tenant Configuration Step by Step Guide
Create an Integration System User
In Workday, open the task “Create Integration System User”
Enter a Username
Enter a Password
Tick “Do Not Allow UI Sessions”
Make a note of the Username and Password for future use
Click “OK”
Exempt Integration System User from Password Expiration
This will prevent syncing disruptions if the password expires and the integration cannot connect to Workday anymore due to authentication errors.
In Workday, open the task “Maintain Password Rules”
Scroll to the bottom to the section “System Users exempt from password expiration” and add the Integration System User to this list
Click “OK”
Create an Integration System Security Group
This step will configure what Workday data the Blink Integration will be allowed to access.
You can create a Constrained Integration System Security Group which will allow you to limit the Integration to only access data from specific organisations within your Workday tenant.
Alternatively, if you want to give access to data of all the organisations within your Workday tenant, you will need to create an Unconstrained Integration System Security Group.
Create a Constrained Integration System Security Group
Open the task “Create Security Group”
In the “Type of Tenanted Security Group” pick “Integration System Security Group (Constrained)”
Enter a “Name”
Add the Integration System User you created in Step 5.1 into the “Integration System Users” field
Pick the organisations you want to limit access to in the “Organizations” field
Choose whether you want to constrain access to just the organisations you have selected or if you want their subordinates to also be accessible by the Integration in the “Access Rights to Organizations” section
Click “OK”
Create an Unconstrained Integration System Security Group
Open the task “Create Security Group”
In the “Type of Tenanted Security Group” pick “Integration System Security Group (Unconstrained)”
Enter a “Name”
Add the Integration System User you created in Step 5.1 into the “Integration System Users” field
Click “OK”
Configure Security for the Integration System Security Group
This final step will determine which Domain Security Policies will be accessible by the Integration System Security Group. For this integration, access to the below Domain Security Policies is required:
Worker Data: Public Worker Reports (GET only)
Worker Data: Current Staffing Information (GET only)
Add the Integration System User Security Group to the relevant Domain Security Policies
Open the task “Domain Security Policies for Functional Area”
Select “Staffing” in the “Functional Area” field
Click “OK”
Select “Worker Data: Public Worker Reports” (under folder “Worker Data: Staffing”) from the list of domains on the left-hand side of the window.
Click “Edit Permissions” at the bottom of the policy panel on the right
Click the “+” button under “Integration Permissions” which will create a new row
Select the Integration System Security Group you created earlier under the “Security Groups column”
Tick only the “Get” column to give only get access to the Integration
An alert will appear prompting you to activate the pending security changes that you are about to make, which you will do in the next step
Click “OK”
Activate Pending Security Policy Changes
Once you have added the Integration System Security Group to all necessary security policies, you need to activate these security changes in Workday.
Open the task “Activate Pending Security Policy Changes”
Enter a comment detailing what changes you have just made to the security policies
Click “OK”
Create a Core Connector: Worker Integration System (optional)
This step is only required if you wish to map non standard Workday User fields into Blink.
Create an Integration System User
In Workday, open the task call “Create Integration System”
Choose a “System Name” and a “System ID”
Note that the “System ID” will be used at a later stage to set up the Workday Integration in Blink
Under the Template section pick “Core Connector: Worker” and click ok
Configure Integration Services
On the next page you will configure the Integration Services
Tick Enabled on the row called “Core Connector: Worker / Worker Data Initialization Service”
Click Ok at the bottom of the page
Configure the Integration Version
Click the related actions menu next to the Integration System name on the top left corner of the screen and go to Integration System > Configure Integration Attributes
Go on row of the attribute called “Version” (required for launch), click the + button to add a row
In the Value column select the latest version available (in this example it is 34.0)
The Restricted to Environment column can be left blank
Click "OK" to validate your choices
In Workday, open the “View Integration System” task and search for the name of the Integration System you just created
Click the related actions menu next to the Integration System name on the top left corner of the screen and go to Integration System > Configure Integration Services to open the Integration Services page
Then go at the bottom of the page in the section called Custom Integration Services
Click the + button to add a row and in the field called Integration Service select Create > Create Integration Field Override Service
On the next screen in “Name” enter the name of field you wish to add to Workday user data that Blinks gets from the Workday API, select “Worker” in the Business Object field and finally enter the name of the field again as the name for the field you are adding to the Worker Data (see example) and click "OK"
Click the related actions menu next to the Integration System name on the top left corner of the screen and go to Integration System > Configure Integration Field Overrides to open a configuration page
On this page, click the name of the service you entered earlier in the panel on the let of the screen (in our example Benefit Group) and in Override External Field, select the field to override
Add your Integration System User to the Integration System you created
Click the related actions menu next to the Integration System name on the top left corner of the screen and go to Workday Account > Edit to open a configuration page
On the next screen search for the Integration System User you set up for the Blink integration (see Section 5) and click "OK"
Configure Security for the Integration System Security Group
Add the Integration System User Security Group to the relevant Domain Security Policies to access workers data
Open the task “Domain Security Policies for Functional Area”
In the “Functional Area” field select the Functional Area under which the field you targeted is secured
Click “OK”
Select the domain under which the field you are targeted is secured from the list of domains on the left-hand side of the window
Click “Edit Permissions” at the bottom of the policy panel on the right
Click the “+” button under “Integration Permissions” which will create a new row
Select the Integration System Security Group under the “Security Groups column”
Tick only the “Get” column to give only get access to the Integration
An alert will appear prompting you to activate the pending security changes that you are about to make, which you will do in the next step
Click “OK”
Activate Pending Security Policy Changes
Open the task “Activate Pending Security Policy Changes”
Enter a comment detailing what changes you have just made to the security policies
Click “OK"
Appendices
Blink User Fields Available
Blink User Fields | Required | Customisable | Usage |
External ID | Yes | No - the integration defaults to the WID (Workday Unique Profile ID)
| System critical, it is used to uniquely identify a Workday user and associate them with a Blink user - must be unique |
Username | Yes | No - the integration defaults to Workday User ID | System critical, it is used to uniquely identify a Workday user and associate them with a Blink user - must be unique |
Active | Yes | No - the integration calculates this fields | System critical, it is used to determine whether to mark a user as active in Blink or deactivate them |
First Name | No | Yes | First Name displayed on the Blink User profile |
Last Name | No | Yes | Last Name displayed on the Blink User profile |
Mobile Phone | No | Yes | Mobile displayed on the Blink User profile - if provided must be unique |
Work Phone | No | Yes | Work Phone displayed on the Blink User profile |
No | Yes | Email displayed on the Blink User profile - if provided must be unique | |
Job Title | No | Yes | Job Title displayed on the Blink User profile |
Department | No | Yes | Department displayed on the Blink User profile |
Manager | No | Yes | Manager displayed on the Blink User profile - drives direct reports teams |
Employee ID | No | Yes | Employee ID displayed on the Blink User profile - although not technically required, it is recommended to sync one. If the customer is transitioning from manual user management, this is critical to ensure existing user profiles are seamlessly taken over. - if provided must be unique |
Company | No | Yes | Company displayed on the Blink User profile |
Location | No | Yes | Location displayed on the Blink User profile |
Start Employment Date | No | Yes | Start Employment Date - can be leveraged in Journeys for onboarding processes |
End Employment Date | No | Yes | End Employment Date - can be leverage in Journeys for off boarding processes |
Custom Fields | No | Yes | Any custom profile fields setup in the Blink admin panel can be mapped to a Workday field |
Workday Fields Examples
Common Workday Fields (non-exhaustive list) |
Employee ID |
Contingent Worker ID |
Worker ID (equals Employee ID or Contingent Worker ID depending on the user type) |
First Name Preferred Name |
Last Name Preferred Name |
First Name Legal Name |
Last Name Legal Name |
Primary Work Mobile Phone Number |
Primary Work Landline Phone Number |
Primary Home Mobile Phone Number |
Primary Home Landline Phone Number |
Primary Work Email Address |
Primary Home Email Address |
Hire Date |
Continuous Service Date |
First Day of Work |
Termination Date |
Last Day of Work |
Primary Job Position Title |
Primary Job Profile Name |
Primary Job Location Name |
Supervisory Organization Name |
Company Organisation Name |
Cost Center Organization Name |