...

• 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.

...

• We are calculating the approvers for the ORG based on the value set in the PTAEO, rather than the requested_for field.
• when we finish the one PTAEO version we will move on to the two PTAEO version

See UC001 UC105 and UC002UC106. We're going to build a simpler version of those in this phase.

...

Else, move on to use the same logic trail for picking a primary and secondary approver as in the NO PTAEO mode of Financial Approval version 2.0.

Please ignore the earlier version of this block.

Phase three

R1020: Financial Approval Workflow, v. 2.0, Two PTAEO mode

...

Let me know if this is not clear. See attachment.

Phase four

Notifications. These are stored in an Excel document.

...

The notifications themselves are not included here.

I will invent them as we need them. There contents will say:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

This will force us to come up with the final version of the text when people complain about getting those notifications :-p

Some of these scenarios already exist and contain existing notifications; there's nothing to do there.

In other cases we will need to invent new notifications from whole cloth, using the fake latin aboveattached in a PDF document.

Follow-up

There is still more to do here

...