Approval Flow

Owned by Dan Franko (Unlicensed)
Last updated: Sept 08, 2017
4 min read

Approvals are either based on financial or organizational hierarchies.  Typically any item with a cost center associated will be routed to the cost center managers for the cost center on the COA.  For supervisory approvals this is usually based on the supervisory organization and some roles such as business partner and strategic business partner.  The roles are always sourced in real-time from Workday.

Configurations

There's a couple of places that approvals are configured.  One place is the CSR Approval Configurations table.  This sets the roles that are used for the approval, the type of approval, and whether or not other approvers are notified when something was approved, which is maybe not something desirable for every item.

Note : The roles for the 'Cost Center' based item is not honored at this time.  It's statically set in the 'Cost Center Approvers' workflow at this time.

These properties control which route approvals take, which actually pre-dates the table above.  In the future it'd probably be best to eliminate the properties in favor of the single table above.


Workflow

Item

Here's where things get a little involved.  The below is probably the simplest example of how this generally works.  

  • First there's a check for if this is a financial or cost center approval.
    • There's a good chance that this won't change again, but the reason it's like this is that they had everything supervisory org based and we anticipated they would change their minds, which they did.
  • If it's org based
    • It determines what the roles are to be passed to the subworkflow for approval
    • Then it invokes the sub-workflow to do the actual calculation and setting of the approvers
  • If it's cost center based
    • We have to make sure we have the actual cost center, it's not always part of the COA string and may need to be calculated
    • Then the cost center approvers sub-workflow is invoked, which sets the approvers
  • Lastly there's a sub-workflow for notifying the secondary approvers
    • This is only the case where there is a secondary COA included for an item.
    • It will determine who the approvers would have been for a COA without actually sending approvals and simply notifies these approvers that their COA was provided and it's assumed that if the other COA was approved, that it's ok to use this one too.

Notes:

  • I believe that the 'Cost Center Approvers' and 'Non-Financial Approvers' workflows could be combined.
  • It might be safe to remove the branching to simplify things, because they probably won't go back to supervisory org based approvals for those items with COA on them.

Cost Center Approvers

The workflow has a couple of parameters, where the return value should go and what the cost center is.

  • First step is to calculate the approvers
    • This gets the 'Cost Center Managers', not honoring the 'CSR Approval Configuration' currently.
    • If the requested by is an approver it's automatically approved and an approval record is entered with a state of approved
      • Otherwise an array of approvers is returned and passed to the approval action
    • If it's approved or rejected by anyone, one of the matching values is returned from the sub-workflow

Non-Financial Approver

This workflow has a few parameters. The requester, which is calculated in a step before, the roles which are approving, and where the return value should go.

  • The time step is a trick to make sure the user isn't blocked
  • The org is calculated based on the user passed in
  • The approvers are then calculated based on the supervisory org and the roles passed in.
    • If the requester is the approver then the request is automatically approver
  • If it's approved or rejected by anyone, one of the matching values is returned from the sub-workflow


Script Include

YaleRoleMembership is used to communicate with the service that provides the roles out of Workday.  It has a debugging property that can be set called yale.debug.YaleRoleMembership.  This used by both approval workflows for getting the approvers.  This service is mostly just a wrapper around the GetRoles service provided by the integration team.