Skip to main content

User Provisioning: Manual and SCIM

An internal guide to the 2 provisioning methods

Updated over a year ago

There are currently 2 methods of provisioning users into Blink: Manually or via SCIM. The SCIM protocol is an open standard that allows for the automation of user provisioning.

Each method supports a variety of approaches in order to best meet our customer's needs. We've included a list of options here and additional details are documented below. The approach you use will be determined by access and availability of data from other systems, the size of the organization, and the number/cadence of movers/joiners/leavers for the customer. Ultimately, there are advantages and disadvantages for each option.

Additional details for each option are documented below. Your approach will be influenced by access and availability of data from other systems, the size of your organization, and the number and cadence of movers/leavers/joiners.

Before deciding which route to go down, it is worth considering the following factors:

  • What it is you would like to sync (please see the list below for mappings). But it’s also worth considering if you would like to sync groups, managers, and what you would like them to have access to. (Please see these docs for more information on Blink teams).

  • Where you would like to sync from (i.e., the source of truth for your user data). A consideration to think about is cost. (Some integrations have an external fee associated with them. In this case we would recommend the CSV processor to avoid this).

  • Multiple sources of truth. e.g. Some users coming from one system and the rest from another.

  • “Cleanliness” of data (We will not allow conflicts with regards to contact details, so each person must have unique contact information. If you decide to sync the data of course).

  • Ability to edit data. e.g. What data you would like users to be able to edit in Blink, once the fields are filled by SCIM they will not be editable and will need to be changed in the ‘source of truth’.

  • The importance of staleness/freshness of the data in Blink. (Some syncs might not update right away. eg. Azure, which will update every 45 minutes).

  • Automatic vs Manual processes. e.g. The CSV-User-Processor, will need a file to be manually added to the SFTP server (this can also be automated, but that set up will need to be done on your side).

The fields that Blink currently accepts are as follows:

  • Employee ID

  • First Name

  • Last Name

  • Job Title

  • Department

  • Location

  • Company

  • Manager

  • Email

  • Phone Mobile

  • Phone Work

  • External ID*

  • Username*

  • Active*

*Required fields for SCIM

Manually Provisioning Users

  1. On a user-by-user basis

    1. Depending on the size of your organization and how often changes are required, this can be quite a laborious task. If you do not want to go down the SCIM route or if you don’t have an external ‘source of truth’ or would like to use Blink as said ‘source of truth’, this is a good option.

    2. Once the Blink instance is set up, those with Admin level permissions can manually add, update, and remove users.

  2. Bulk upload of users

    1. We would suggest this for any organization that doesn’t want to go down the SCIM route, irrespective of size. Or for anyone having user info in different systems that would be collated prior to upload.

    2. Once the Blink instance is set up, those with Admin level permissions can download a template for updating users. After it's filled out, this can then be uploaded to get the users into Blink.

Syncing via SCIM

For any of the below options, the fields that are synced across will be locked in Blink. This is to stop people from updating their information and causing discrepancies with the ‘source of truth’.

If contact details are not synced across however, we will leave these open for editing. This is to allow people to add their own contact details should they wish to. All other fields will remain locked however.

There are a couple of required fields (see those above with an *), these are for us to be able to identify the users more precisely and to determine what actions need to be performed on said users.

Leverage our SCIM API

We offer comprehensive API documentation if you would like to build out a user-sync integration yourself, which can be found here. Please see the ‘SCIM API’ section at the bottom of the far-left column.

We have some supplementary documentation around SCIM best practices here.

Via a user-sync that we have built

We currently have integrations built with the following systems, please ask us for more details should you need them.

These integrations are self-serve: we will provide you with a SCIM token and the documentation needed. See the links on each type for more details.

  • Built or coming soon:

    • ADP Workforce Now

    • Workday

    • UKG Ready

    • ADP Vantage (Coming soon)

    • UKG Pro (Coming soon)

For these we will need credentials to access the APIs. We will then perform what we call a “Dry-Sync” and share the data with you to make sure you are happy with the what the sync will look like.

Via an external data source with a custom integration

We are always looking to integrate with new systems. Please let us know if you have a particular system that you use that you would like us to integrate with.

We will need some API docs to see what is possible. If the sync is possible, we will need access to the APIs and a sandbox for testing.

Leverage our 'CSV-User-Processor' utility

We have built a system which leverages SFTP uploads to import users into Blink.

It accepts CSV or Excel files with your users’ data in it. We will need a sample file that you will be uploading and mappings for the above fields available in Blink.

We will then configure an SFTP server and give you access to it. You can then drop the files onto the server whenever you so wish. We will then email you the results of the upload, detailing the successful updates and if there were any conflicts or errors. We have had people automate this. Please let us know if you would like to discuss recommended practices.

Advantages and Disadvantages

Type

Option

Advantages

Disadvantages

Manually

Instant updates

Full control

Laborious for many records.

Instant updates

We provide a template but you will have to fill it out and manually upload the file.

SCIM

API

Full control and flexibility.

Customer has to build it.

Built user-sync

Automated.

Quick setup.

Updates will filter through when the sync runs. Some are instantaneous, some are not.(All within an hour though).

Cost (some integrations have an external cost involved, it will depend on where/who you are syncing from).

Unbuilt user-sync

Can use your current source of truth (as long as we can integrate with it).

Automated.

We will have to scope the work and fit it into our roadmap.

Cost (some integrations have an external cost involved, it will depend on where/who you are syncing from).

CSV-user-processor

No cost involved.

Instant updates (once the file is uploaded).

If not automated then you will have to manually upload the file to the SFTP server.

Development Timeframes

Azure AD

Self-serve

Okta

Self-serve

ADP Workforce Now

2 Days*

Workday

2 Days*

UKG Ready

2 Days*

ADP Vantage (Coming soon)

2 Days*

UKG Pro (Coming soon)

2 Days*

Custom User Sync

1 Week - 3 weeks*

CSV Processor

1 Day*

* Once we have access to the data in the format that we need it in, and we have agreed on a timeframe.

Did this answer your question?