Anyone else using Workday & AD with WDaaM? Writeback enabled? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Eric TiptonEric Tipton 

Anyone else using Workday & AD with WDaaM? Writeback enabled?

Looking to ask some specific questions and exchange info. Having run into more than a couple scenarios in relation to WDaaM where support doesn't seem up to speed and wanted to see if others are experiencing the same issues that I am.  

Thanks in Advance
Shawn SaucierShawn Saucier
We are also trying to get there, but having a couple of issues as well, and that's prior to Writeback being enabled.

Things I've encountered:
  • Extended attributes and reporting are really finickey.  If the report isn't configured perfectly, API testing fails.
  • If you have ~5000+ users (active and term in our case), the report times out on OKTA's side.  The workaround (as outlined in the integration guide) is use the Custom Report JSON URL with a query for a specific user
    • Example:  https://<domain><report owner id>/<report name>?Employee_ID_Prompt=<WID of place holder user>&format=json
    • Note:  The "employee_id_prompt" in the example above is simply the name of the prompt in the WD report. 
    • Note:  The way OKTA uses this is it sees that as a "placeholder" and queries all individuals using the WID.  it's kinda  funky, but seems to work.
    • Note:  OKTA WD Integration Guide says that it has to be an ACTIVE employee, and to ensure that the user is never terminated.  That of couse is highly problematic, as I've yet to be at a company where ANYONE is guaranteed to stick around.  We made it work with a terminated user, but OKTA support "cannot guarantee this will continue to work."
  • Telephone numbers are not retaining format as configured in mapping
    • JIRA Bug OKTA-95757 created (Phone number mapping truncates the hyphenated numbers), and unresolved as of July 27
  • There seems to be a a difference in behavior whether using provisioning groups or not.  I'm still trying to understand the bahavior (which led me to your post)
    • Originally, I configured our Preview environment with WDaaM and didn't have provisioning groups.  All users were synced. 
    • Once I had the WD admin create provisioning groups, and those groups synced down, all the users seemed to have been deprovisioned, and had to be re-provisioned by assigning the provisioning group to the WD app
    • This causes a provlem for us, as we don't want our contractors logging into Workday, even though we have Contractors provisioned THROUGH workday.  As far as I can tell, the user has to be assigned the WD app in order for WD to be master (Hopefully someone can clarify this).

Mybe if we mind-meld, we can figure this out together.

Eric TiptonEric Tipton
Hey Shawn,

Good to know I am not alone...since it does feel that way sometimes. ;-)

We are als using the JSON report for additional attributes and it's working fairly well. I had just joined our company prior to going live with WDaaM and have alwasy been a bit concerned about the report being under a specific name. 

Regarding phone numbers -- are you referring to mapping from Okta to Workday (Writeback)? We are only doing email for now.  

We aren't using the WD provisioning groups. We thought we would move in that direction but since we use an AD script to fill in other attributes, we have opted to also let it handle the app assignment. I also like doing it this way since I have limited visibility into the WD side of things.  The WD cost center, location & other fields are pushed from Okta to AD and then the script uses theem to determine which groups they get added to and thus what apps they get. 

We assign everyone Workday, including contractors, but yes, I believe the app needs to be assigned if you want the user to be mastered by WD. Aside from setting up a separate SWA app for contractors (and I am not sure if that would work), the only thing I can think of is to set up a sign-on policy (in the WD app in Okta) for contractors, denying anyone in the contractor group access. The chiclet would still show up but be greyed-out for contractors. 

...I will respond in a bit with our specific issue with Writeback since I am curious if you are experiencing the same.

Eric TiptonEric Tipton
Hey Shawn,

I hope the info I provided yesterday was helpful. I am happy to provide more details as needed. 

We are experiencing an issue with Writeback and wanted to see if you are seeing the same in your environment. For a portion of users, Okta is not able to write back to Workday (again, in our environment we are only writing email address). We get the following error in Tasks under "Profile push updates encountered errors":
An error occurred while pushing a profile update to this app.
Automatic profile push of user Adriana Botto to app Workday failed: Unable to update personal info for Workday employee: Validation error occurred. Element Content 'Degree_Reference' is required, on internal element 'Education History Data'

Eventually, we discovered that we get this error for any Workday user that has added a SCHOOL (Professional Profile, Education, Add) but does NOT enter anything in the DEGREE field. The user is able to save their update in Workday but when Okta attemps to write back the email for these users, that's when the error occurs. The explanation I was given from Okta was that the field  'Degree_Reference' is set as required for ...but only when acessed by API. 

What is not clear is that if this is something unique to our environment. It seems likely that any fix needs to happen on the WD side -- but I am attemtpting to gather as much info as possible before involving my WD Admin or WD Support. You can easily test by adding a school without at degree to your own WD profile per below. If you have multipl schools entered - ANY school (including High Schools) without a degree will cause the Writeback issue. 

Any other WDaaM users w. Writeback enabled, feel free to play along ;-)

 . Workday Education Profile
Tiffany LTiffany L
Eric & Shawn,

We're using WDaaM and after a few bumps in the road transitioning to that process, we've actually gotten it pretty smoothed out by now. We don't have write-back enabled as it's a relatively new feature and there's very little documentation available. We're using the JSON report to populate additional attributes into Okta and there are definitely some nuances to using it. For example, I tried pulling job profile at one point and depending on which object I pulled it from, it would either be blank or not when sent to Okta (although it displayed just fine in the Okta report itself). I never got a real answer as to why that happened from Support, but my workaround fixed the problem.

I've also actively avoided using provisioning groups in Workday as it's a pretty messy implementation. We're using Groups and Group rules within Okta itself which is much easier to deploy and maintain, especially since it allows for very detailed rules.
Eric TiptonEric Tipton
Thanks for sharing your experience, Tiffany.

It's good to hear of your positive experience with Groups & Rules in Okta. It was a fairly new concept when we turned on WDaaM and I was a little hesitant. I need to do some testing and see how/if it can help us. 

You are correct in the lack of documentation for Writeback. I will also warn anyone that is looking into enabling it that the Okta documentation regarding the needed Workday permissions to be able to write back is completely incorrect. I understand that Okta is in the process of updating the document bit I am happy to provide specifics as to what we neede to do on the WD side to anyone that's interested. 

It was a little painful to get Writeback working  -- lots of trial and error getting the Okta Expression to autocreate the email correct, enabling and using Attribute Level Mastering (ALM) so that AD is the master for email, etc. However, once I got past the obstacles,  it has worked pretty well (aside from the problem with the missing Degree field mentioned above). Writeback allows us (IT) to take back the responsibility from HR of choosing an email address. We are also using an Okta Expression to create their Okta/AD username instead of using the Workday username. Prior to enabling Writeback, we were getting usernames/emails that did not match our standard and would have to ask HR to make changes on their side which slowed down the new hire process a great deal. Writing back the phone number would be usefull for a lot of organizations as well. We don't issue phones to the majority of our employees so it's not quite as helpful in our environment. 

In regards to the specific issue I am having with Writeback, I have been in touch with Workday as well as Okta Support and will let you know when I have a resolution. The suggested workaround is to have anyone missing the field to add it.....but that's not something that will work for us and is not scalable. 
Tiffany LTiffany L
We adopted group rules while it was still in Beta and I'm pretty comfortable with it at this point. My only "gotcha" that you should be aware of is that there is no way for you to use an Okta system setting like user status as part of the rule. For example, if you wanted to create a group that is for all Permanent Employees using the Workday "employee type" field, it would assign this group for ALL users that exist in Okta with that employee type and would not limit group assignment to active users. There is no filter for Okta user status = active.

I have an idea out there for this feature ( but Okta support/product management hasn't seemed to think this is a very important issue.
Eric TiptonEric Tipton
Thanks again Tiffany. Another question for you - how are you dealing with Contractor to Employee conversions? This process disables the account in Okta & it's causing us a LOT of pain. See details here: