This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Workflow if then to select Approver

Within our organization are three departments:  Dept 1, 2, and 3.  These three departments will use the same workflow.

However, when an employee sends a document for approval and selects Dept 1 in the metadata.  I would like the approver to be the Manager of Dept 1.  The same goes for Dept 2 and 3.

I'm trying to come up with a workflow that can do this.  One option I could do is to create 3 separate workflows.  However, all three will follow the same process and the only difference is the approver.  I'm trying not to have 3 workflows to update every time there is a change in the process.

What is the best way to implement this?

Parents
  • Assuming you have a Department object type and that you have Manager as a property in the Department Class you should be able to use indirect references for the approver like this department.manager.m-filesUser

  • I do no have a separate Department Object Type.  All I have is a Document Object.

    I was thinking more of putting an If-then statement in the Preconditions of the workflow state.  In the precondition, I will put If Department=Dept1, then Manager=LastName.Firstname.

  • That would require different parallel workflow states with different action settings in each state depending on which department is selected. This can be done, but it is not a dynamic configuration. It will not adapt to any changes in your organization, and it will not be easy to maintain. Therefor I would advice against it.

  • As we have similar use cases, I could as well highly recommend what bright-ideas suggested. I would highly recommend to first step back and design whole business structure in form of object types before designing first document types. This would force you to think about your business, business dependencies and possible metadata to describe documents. After that solutions are quite easy to design and flexibility is re-usable.

Reply
  • As we have similar use cases, I could as well highly recommend what bright-ideas suggested. I would highly recommend to first step back and design whole business structure in form of object types before designing first document types. This would force you to think about your business, business dependencies and possible metadata to describe documents. After that solutions are quite easy to design and flexibility is re-usable.

Children
No Data