<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D50Z00008G7UhHSAVOkta Classic EngineLifecycle ManagementAnswered2024-04-30T09:18:25.000Z2015-09-03T17:32:16.000Z2018-08-12T04:15:09.000Z
  • j5v7c (j5v7c)

    By now you’ve no doubt heard about Okta’s Universal Directory, or the Okta Expression Language.  We wanted to take an opportunity to talk about some real world examples of how we’ve been using it with some customers to achieve some advanced provisioning functionality.

     

    The Last Shall Be First

    A scenario we see quite often is using an alternate format for your display name.  For this example rather than being “John Smith”, we want display name to be “Smith, John”.  With a simple concatenation we can flip the order of the names around.

     

    source.firstName + ", " + source.lastName

     

    Once you understand the syntax it is easy to see how you can manipulate the formatting of any user attribute.

     

    No Email? No Problem!

    Another issue we often see when provisioning a new employee account to Okta, particularly from an HR system like Workday(https://www.okta.com/solutions/hr-driven-it-provisioning.html) is the required email field.  We’ve got a brand new user who doesn’t exist in any IT systems yet, and thus does not yet have an email address, but email is required to create an Okta account.  This can be a real chicken or egg type problem when you’re trying to provision an account to an Active Directory, or Google Apps.

     

    A simple custom mapping allows us to create a placeholder for email so we can provision the account into AD or Google apps where we create a real email address.

     

    The following expression checks to see if the email address is populated in the source application, if it is not, will get the username and add a string to the end.  If the email is there, it will flow as it normally would.

     

    source.email==null?source.userName + "@domainsuffix.com":source.email

     

    Keep in mind, if your users are Okta mastered, they’ll need to have a valid email they can access in order to activate their account, but this can be a great placeholder so you can continue to provision accounts.

     

    Original Author: Cody Suders, Technical Consultant - Professional Services, Okta

     

     

    Expand Post
    Selected as Best
  • j5v7c (j5v7c)

    By now you’ve no doubt heard about Okta’s Universal Directory, or the Okta Expression Language.  We wanted to take an opportunity to talk about some real world examples of how we’ve been using it with some customers to achieve some advanced provisioning functionality.

     

    The Last Shall Be First

    A scenario we see quite often is using an alternate format for your display name.  For this example rather than being “John Smith”, we want display name to be “Smith, John”.  With a simple concatenation we can flip the order of the names around.

     

    source.firstName + ", " + source.lastName

     

    Once you understand the syntax it is easy to see how you can manipulate the formatting of any user attribute.

     

    No Email? No Problem!

    Another issue we often see when provisioning a new employee account to Okta, particularly from an HR system like Workday(https://www.okta.com/solutions/hr-driven-it-provisioning.html) is the required email field.  We’ve got a brand new user who doesn’t exist in any IT systems yet, and thus does not yet have an email address, but email is required to create an Okta account.  This can be a real chicken or egg type problem when you’re trying to provision an account to an Active Directory, or Google Apps.

     

    A simple custom mapping allows us to create a placeholder for email so we can provision the account into AD or Google apps where we create a real email address.

     

    The following expression checks to see if the email address is populated in the source application, if it is not, will get the username and add a string to the end.  If the email is there, it will flow as it normally would.

     

    source.email==null?source.userName + "@domainsuffix.com":source.email

     

    Keep in mind, if your users are Okta mastered, they’ll need to have a valid email they can access in order to activate their account, but this can be a great placeholder so you can continue to provision accounts.

     

    Original Author: Cody Suders, Technical Consultant - Professional Services, Okta

     

     

    Expand Post
    Selected as Best
This question is closed.
Loading
Setup of UD for Provisioning