<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
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D54z0000ABuXX6CQNOkta Identity EngineWorkflowsAnswered2024-07-16T21:29:56.000Z2024-07-08T22:47:47.000Z2024-07-16T21:29:56.000Z

DavidQ.83547 (The National Domestic Violence Hotline) asked a question.

July 8, 2024 at 10:47 PM
Displaying previous and updated values for changed attributes in Okta import logs.

There are a few similar posts on this topic, but our use case is a little more unique from what I have been able to find so far.

 

In our use case, the HR system (Paylocity) is not a profile source for specific reasons. When the import job runs, the updated attributes are applied to the users app assignment, but not updated on the users Okta profile. In the logs we can see the updated attribute and in the app assignment we can see the current value, but we cannot see the previous value.

 

I am building a Workflow to notify us on these actions and being able to evaluate the previous value and the current value would be immensely helpful in our process.

 

In Workflows, using the "users profile update" card can't be used because technically the users profile isn't updated. Only the data in the app assignment. Has anyone Dev'd a workaround for this?

 

There was a request from around 5 years ago (https://ideas.okta.com/app/*/case/106132), but that has since been closed. Another was created 7 months ago (https://ideas.okta.com/app/*/case/192623), but unless is gets traction, it will probably end up being dismissed as well.

  • 4 answers
  • 743 views

  • TimL.58332 (Workflows)

    @DavidQ.83547 (The National Domestic Violence Hotline)​  -- As Mihai indicated this isn't currently feasible (at least not at scale). This is essentially a technical limitation to how the API's work. The "Update User" endpoint action that changes profile data just sets a new value. When that new value is set a profile update event occurs and indicates which attributes had their values changed.

     

    The previous value isn't required/relevant in the action that Updates the profile and because of this there is no way for the "event" to know what the previous value was as it fired in response to the change being made..

     

    You would need to essentially have a "Duplicate" of all of the user data stored somewhere that is accessible for a "lookup" that is then updated after the lookup / report was made. Which is why "not at scale" was mentioned initially. If you had a small number of users you could easily store the data in a table/spreadsheet and make lookups/modifications and the usage wouldn't really be a problem. However, its a "Red Zone" use case and will fall apart at scale. https://help.okta.com/wf/en-us/content/topics/workflows/workflows-system-limits.htm

    Expand Post
    Selected as Best

  • Mihai N. (Okta, Inc.)

    Hi @DavidQ.83547 (The National Domestic Violence Hotline)​ , Thank you for reaching out to the Okta Community! 

     

    I double-checked with my colleagues and confirmed that this is not possible due to the way the data would have to be stored. 

    That being said, we'll leave this question open in case anyone in the Community came up with a custom solution.  

     

    If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you. 

     

    Hope my answer helps! 

     

    --

    Ask Us Anything thru 7/14: Okta WIC leadership want to hear from you

    Expand Post

  • TimL.58332 (Workflows)

    @DavidQ.83547 (The National Domestic Violence Hotline)​  -- As Mihai indicated this isn't currently feasible (at least not at scale). This is essentially a technical limitation to how the API's work. The "Update User" endpoint action that changes profile data just sets a new value. When that new value is set a profile update event occurs and indicates which attributes had their values changed.

     

    The previous value isn't required/relevant in the action that Updates the profile and because of this there is no way for the "event" to know what the previous value was as it fired in response to the change being made..

     

    You would need to essentially have a "Duplicate" of all of the user data stored somewhere that is accessible for a "lookup" that is then updated after the lookup / report was made. Which is why "not at scale" was mentioned initially. If you had a small number of users you could easily store the data in a table/spreadsheet and make lookups/modifications and the usage wouldn't really be a problem. However, its a "Red Zone" use case and will fall apart at scale. https://help.okta.com/wf/en-us/content/topics/workflows/workflows-system-limits.htm

    Expand Post
    Selected as Best

    • DavidQ.83547 (The National Domestic Violence Hotline)

      Thank you for the in-depth answer! That very clearly explains the current limitations. What do you feel the tipping point of that scaling issue could be?

      • TimL.58332 (Workflows)

        @DavidQ.83547 (The National Domestic Violence Hotline)​  -- The scale problem is due to needing to keep an up-to-date copy of every profile attribute for every user in a second location. At really small numbers it would be easy enough to monitor/maintain consistency but at any sort of scale it would be near impossible.

         

        For example: Lets say some major change happens in your environment like you add in some new app which causes schema changes to the users profiles. That "Secondary" location wouldn't have the schema changes and if they were not in place before they would all be "failures" from a huge block of events kicking off the flow. Just the fact that you are kicking off a huge block of events could be problematic in itself. There are likely many other "gotcha" scenarios also which is why this type of use case is considered completely unsupported (Red zone).

         

         

        Expand Post
This question is closed.
Loading
Displaying previous and updated values for changed attributes in Okta import logs.