I have created an SSD flow for creating a case instance, and it returns the entered user details along with the CID. After this, I’m not sure which step to follow.
In the assignment file, it mentions using REELS for identifying whether the case is STP or NON-STP.
So, should the details returned by SSD (user details + CID) be sent to REELS after receiving the data in ALPHA?
Can anyone explain the correct flow of integrating REELS after creating a case instance using SSD? @Sam@Simphiwe@Hariharan_J
What you will be sending to REELS is everything required to check STP or N-STP.
To integrate REELS, you have two options:
1. You can integrate REELS straight to alpha.
2. Integrate it to an SSD flow and call that API on your alpha.
According to the masterclass guidelines, the case instance is created when the STP fails.
The STP fail would trigger the case creation which will be assigned to an underwritter.
With that being said, since the case is only created when the STP fails so you have to:
1. Integrate REELS on your SSD flow first before creating a case.
2. Depending on the REELS output create a case(which will be a human task assigned to underwriter) or generate the policy.
Oh okey. So we need to create a master data based on the required customer fields and use that MT for checking stp or not if it is not an STP use API node for calling the SSD to create a case instance.
Im i right? and also what will be the rules for checking whether it is a STP or NO STP and finding the price for the insurance ? @Simphiwe
and also as per your earlier response we will create a REEL there we will get the user data and create case instance using SSD and how we can pass the SSD data to the alpha ? because we are triggering the SSD from REEL right so how we can send the data to ALPHA ?
The SSD flow could start by first checking the STP through an integration with REELS. Based on the output returned from this check, then decide whether to create a case or not.
This SSD flow can be triggered via an API call made from Alpha.
During the masterclass, you are given the flexibility to define many aspects of the process yourself.
This is why there are scores allocated for:
On your SSD, you will have an API that gets triggered from your Alpha application when a button is clicked on a global page.
The SSD flow will begin with an HTTP-In node as the entry point. From there:
Check STP using the REELS rule
The first step is to call the REELS rule to determine if the policy qualifies as STP (Straight-Through Processing) or N-STP (Non-Straight-Through Processing).
Based on the REELS response:
If STP: Generate the policy automatically.
If N-STP: Create a case, which represents a set of human tasks that need to be completed manually.
Stepping Back – Main Objective
The primary goal of this policy underwriting system is to generate a policy and send communications at each stage of the process.
However, before a policy can be generated, the system must first determine whether it follows the STP or N-STP route:
STP: Fully automated process → Generate policy and send communications directly.
N-STP: Manual intervention required → Create a case with tasks for human review, then proceed to generate the policy once the tasks are completed.
Oh okey thankyou now i got the flow but i have a doubt we need master data while working with the REEL right so do we need to create a master data and create rules based on the MT before triggering the SSD from Alpha ? @Simphiwe
You can create a masterdata if you want to but you can also use the one you uploaded for the REELS task so that would basically depend on your policy underwriting system requirement.