• State Verified Answer
  • Replies 6 replies
  • Subscribers 113 subscribers
  • Views 1021 views
  • Users 0 members are here
Options
Related

Separate workflows for different object types?

mark cook
9 months ago

Hi all,

I'm curious if there is any best practice/recommendations around splitting out different types of objects into different workflows & if this is even possible?

With my engineer head on, I like the idea of dealing with users in one workflow, then workstations in another workflow. However looking at workflow configuration, whilst I see you can "Skip" creating "new" Users/Groups it will still update any matched ones. So, it still looks to process all object types.

Is it recommended to just use one workflow for everything?

Many thanks in advance for any feedback.

Cheers,

Mark.

Parents
  • 0 9 months ago

    This is an interesting question and I have never really thought about it this way.

    This is probably because the Change Workflows I create are 99% of the time reacting to a user or group-related event. Thus, when I build them, the start condition / trigger always references either user or group related actions (create, update, deprovision etc.) and thus your suggested segregation by object class takes care of itself. FWIW, I believe there does exist in the Change Workflow start condition object class dropdown an "any object" option but I have never used it.

    As for Automation Workflows (which don't react to an in bound transaction but rather, are usually scheduled), I use them most often to perform out-of-band (i.e. non real time) processing of objects that I have "queued" (usually by setting a flag attribute that gets them included into a Managed Unit that the workflow enumerates the contents of).  An example of this would be additional provisioning processes that need to occur on a new user but don't need to occur right away and/or need some time delay before they occur.  Again, 99% of the time, in my world this has to do with user objects but that's just the nature of my customers' needs. So to your point, I would likely segregate Automation Workflows by class by default.

    Hope this helps.

Reply
  • 0 9 months ago

    This is an interesting question and I have never really thought about it this way.

    This is probably because the Change Workflows I create are 99% of the time reacting to a user or group-related event. Thus, when I build them, the start condition / trigger always references either user or group related actions (create, update, deprovision etc.) and thus your suggested segregation by object class takes care of itself. FWIW, I believe there does exist in the Change Workflow start condition object class dropdown an "any object" option but I have never used it.

    As for Automation Workflows (which don't react to an in bound transaction but rather, are usually scheduled), I use them most often to perform out-of-band (i.e. non real time) processing of objects that I have "queued" (usually by setting a flag attribute that gets them included into a Managed Unit that the workflow enumerates the contents of).  An example of this would be additional provisioning processes that need to occur on a new user but don't need to occur right away and/or need some time delay before they occur.  Again, 99% of the time, in my world this has to do with user objects but that's just the nature of my customers' needs. So to your point, I would likely segregate Automation Workflows by class by default.

    Hope this helps.

Children