Hi @matt hoss 

Never had to restrict users from approving their own records, all the time the assumption was that the Approval Map would be configured in a way that delegates the approval flow to another superior user/group.

It even feels natural - when you want to have a document approved/rejected (for example, a receipt refund for a dinner with a client), you expect the approval to come from your manager - immediate or higher.

If you want tree-like relations - you can make several steps with conditions which are going from bottom to the top of the chain of command.

So my first thought was to say that this is a sign that something is configured incorrectly (or, for some cases - that the general flow of Approval Assignment doesn’t fit your use case).

If I had to implement this, I’d look into creating a child class from EPApprovalAutomation - a special class, responsible for adding approval magic into your graph.

It has an Assign method, responsible for searching and assigning approver to the record, based on the associated Approval Map. It uses the DoMapReExecution method to search for assignment rules, while in turn delegates it to the MapReExecutionInternal. MapReExecutionInternal is protected, so we can try to override in the child view class and add validation that the approver isn’t the same as the owner.

Sadly this is not standard available as a general rule, so you have to add each person in the approval map as an owner and their approver if that person is the owner.

Other option is to look at a customisation.

An alternative is to add an unbound bool field (let say IsOwner) to any DAC you want to perform restriction (i.e. POOrder, ...) that compares the CreatedByID to the Current AccessInfo UserID and if match then true otherwise false and use this field in you Approval Map Condition where is equal to False.