Workflow if then to select Approver

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

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.

Totally agree. We resisted initially to create a Department Object (We actually use smaller Team Object) 

When we first launched M-Files, we just used a single select value list for our Departments - huge headache - don't recommend. 

We now use a Team Object, which is related to the Employee Object. The employee object is tied to our Active Directory and updates every night. Some employees are managers - so there is a property on the Employee object that indicates this. The Employee also has a terminated date. 

The best benefit of this approach is for those situations when an employees works with more than one team. This approach handles this so documents that are restricted to Team 1 or Team 2, then can access because they're a 'member' of both

Thank you all for your replies.  Based on your comments, it sounds like this is the way to do it right. I will start creating different Objects.  In our original design, I stayed out of creating objects other than documents, but now I see that it is necessary.