...
- add two fall-through modes. See later comments.
- when we finish this one we will move on to the one PTAEO version
- when we finish the one PTAEO version we will move on to the two PTAEO version
I've attached a revised version of the attachment. The UC versions are revised. Please ignore the earlier versions of these blocks:
I've now created the data. See UC004 UC108 for the condition we are modeling here. And see UC005 UC109 for the algorithm for determining the primary approver.
...
START admin is a new field, and we are going to statically define it directly in the approval workflow. The sys_id for the START admin is:
09bea76ad8d46c007ac0638b5167dcc6
which is Nancy Scanlon.
This block is revised, please ignore earlier version.
The general idea of financial approval version 1.0 is sound. But the phase where we choose an approver is more complex, and the way we fall through to a secondary approver after three days will also need to be more complex:
1) start with trying to assign OpsMgr as primary approver. Start the three day counter. Then execute UC003, but with modifications that are not in that document (oops)UC105. We always want to escalate. If the ORG has a Null value for LeadAdmin, instead assign Bolt Member. If null value for Bolt Member, assign START admin.
2) if null OpsMgr, set primary as LeadAdmin. Start the three day counter. Then execute UC003, but with modifications that are not in that document (oops)UC105. We always want to escalate. If the ORG has a Null value for Bolt Member, then set START admin as secondary.
3) if null LeadAdmin, set Bolt member as primary. Start the three day counter. Then execute UC003, but with modifications that are not in that document (oops)UC105. We always want to escalate. The only secondary we can escalate to is START Admin.
...