Technical Articles
SuccessFactors integration with Okta
In this blog post we will learn about high level basic details about integrating SuccessFactors with Okta. I will explain the simple approach for the integration.
Okta is an enterprise-grade, identity management service, built for the cloud, but compatible with many on-premises applications. With Okta, IT can manage any employee’s access to any application or device. So if access to SuccessFactors is also provisioned by Okta in that case integration between two needs to be built keeping certain points in mind:
There can be two approaches for the integration:
- Using Okta standard connector- It is straightforward and simple. Okta can connect to SuccessFactors instance using its own connector. No separate connector or middle-ware is required.
- Using Integration center- You can use the scenario where destination type is REST . This option will need lot of effort in setup but using it even custom portlets and other such complex logic can be built in integration for mapping ad updates.
Now let’s look at the option 1 of using standard Okta connector. Here are few points to note:
- Okta has its own connector which helps it to connect directly to SuccessFactors, no middle-ware or separate connector is required.
- Okta reads only user records that have Job/employment data records in SuccessFactors and are active.
- Future dated hiring records can also be read by Okta and how far should that be allowed depends on settings in Okta.
- Okta will have current records and won’t store history of the user. So only delta changes will flow from SuccessFactors to Okta.
- Okta reads data records including custom fields only from standard portlets and can’t read custom portlets/views/custom MDF views.
- Okta can read contact details which are marked as primary. e.g only email id or phone number that is marked as primary is read by Okta and other contact records are not fetched. So make sure required work email and work phone number is always marked as primary. Implementing business rule to default such records can help a lot.
In this screen shot , we can see under contact details Business email and business phone number is stored and both are marked as primary as is highlighted by the star at the end of the record.
- Okta can write back only contact details i.e. email id or phone number records which are marked as primary, other records can’t be updated by Okta.
- Integration is seamless and no jobs would need to be scheduled in SuccessFactors for integration.
In this blog post i have tried to summarize and mention all the important points that i had to work on while integrating SuccessFactors with Okta for a customer. I have highlighted the straight forward way for the integration.
Hi Rohit Bindroo
First of all, good on you for a decent attempt for this initiative. However, there are a few key points that are missing or need revision.
The blog is high level and doesn’t provide a Consultant on “how to”. It just explains a few features which are already documented by Okta. There is a lot more to SuccessFactors and Okta integration. A simple search on Google will guide you to many artefacts that you can refer to. I encourage you to research more on it and revise the blog.
The diagram is incorrect. Both AD and SF should not send data to Okta. A best practice pattern could be SF to Okta to other downstream apps such as AD and others, and back the same way with email ID, phone number, user name updated.
Thanks
Arijit Das
Hi Arijit,
Thanks for your comments. In this blog i just wanted to provide only high level details and few important points to note when we start working on integration. Yes, you are right many points are available on Okta site but my aim was to share my experience while working on this integration. This diagram is what is available on Okta site. SF is the source and in integration SF does send data to Okta and then Okta forwards the data to AD and there is certain data like generated email id or assigned/allocated work phone, this info can be sent by AD to Okta. May be its not the best practice but that was the scenario i had to encounter. I will try to update the blog further.
Thanks.
Hi Rohit Bindroo thanks for the reply. The pic looks fine at second glance. However, for clarity AD should be represented on the RHS. As you can appreciate, it is easy to get confused at a first glance as it appears that both AD and SF are writing to Okta simultaneously. However, the flow is
SF -> Okta -> AD to provision the User account in AD, and AD -> Okta -> SF to write back the username and EmailID to SF.
Use this diagram here
Cheers
Arijit