Workflow Structure, Promotion Offer Flow

Question

would really appreciate your help, in terms of the implementation details, as well as the 2 clarifying questions I have below:

Context:

Creating an offers promotion workflow. The offer has an expiration date (We start counting down after the offer is accepted.)

User can choose to decline offer (workflow then stops) Once offer is accepted, they will have 7 days to try and redeem cashback points. Once they meet the cashback points requirement, we will credit the the points to their account

1st question: is the below logic correct? and That I am using signals.

2nd question:, I am listening for signals in the parent workflow on say 'parentSignal' channel. Listening for "ACCEPTED", "REJECTED", "CANCELLED". In the child workflow I am listening for "10%CASHBACK", "50%CASHBACK" "100%CASHBACK" as well as "CANCELLED" as the admin can cancel whenever he/she wants to. IS THIS THE CORRECT WAY TO TRIGGER WORKFLOWS?

How I'm thinking of writing the workflow (however, I can't seem to get it to work properly in the Cadence GUI, when I try to emit different signals)

Parent workflow (OfferWorkflow)
   Listen for signal (signal received from external service)
      if accept, start execute Child Workflow (cashback workflow)
      if reject, end workflow
      if cancelled (by admin, end workflow, cancel any cashback progress)


child workflow (cashbackWorkflow, with expiration time) 
   Listen for signal, once 10% of cashback requirement is met (send email) 
   Listen for signal, once 50% cashback is met (send email) 
   Listen for 100% cashback is met 
      // Perform credit (make call to external function)

There will be an external service that will be sending signals. The external service knows the progress. For example, if a user spends up to 10% of cashback, then we send a signal to the cadence workflow.

Answer 1

1st Q: Logic wise, it's correct. I don't see a problem.

2nd Q: this can work, however, you need to be careful about how to send the cancel signal to childWF. If you let external service to do it, it may be a consistent problem. If you let parentWF to do it, you need to make sure parent WF is not closed.

Overall, your design works, but it can be improved.

The main issue of your design is about using childWF. Your workflow will be much simplified, saving lots of edge cases if you don't use childWF. Conceptually, childWF is useful if your parentWF is too complicated that you want to break down, and also get a result from childWF. See here for more details about when you should use childWF: What is a good use case for a child workflow in Uber Cadence?

If not using childWF, the pseudo code becomes this:

OfferWorkflow(input)
  1. init offer state(local variable object), and you can register a [query][1] handler for this object. 
  2. In a loop, listen for signals for operation:
     2.1 accept: check state, if not accepted, then accepted, and start a timer with a future operation:
       2.1.1:
          when the timer fires, check state, if accepted, then end workflow(accepted->end)
     2.2 reject: check state, if not accepted, then end workflow(accepted->end), if accepted, you may ignore or end workflow
     2.3 cancel: end workflow(accepted->end)
     2.4 10% or 59%: check state, if accepted, then send email
     2.5 100% : check state, if accepted then perform credit and then change state accepted->credited. 
For error handling in above, eg, 100% for a unaccepted offer, you may emit logs/metrics for monitoring.