Sub Case Vs SubFlow

Often during a design discussion, we hear questions / discussions like, why do we need a sub case for this task, cant this be done by a sub flow? Whatever a sub case can do, sub flow can do the same, let’s not complicate by having sub cases. Contrary, we also hear, design a sub case, we can extend it later if required. All of these questions / discussions are valid, but not directed or supported. Here is a small article, describing when to use which Design Paradigm, which would help us make above design discussions directed and supportive with data points

Given the capabilities for each, there are many ways to compare pros and cons of each. However, the scenario or requirements should be detrimental  of the design paradigm.

- Sub Flows, in this discussion represent Sub Process / Spin Offs / Split for Each / Split for Join

- “Task” has to be read either as Sub Flow or Sub case depending on the context

Dependency Management: Is the a requirement to Start off the “Task”, when certain conditions are met. Example: StartLoanEvaluation “Task” needs to be performed only after Customer submitting required Proofs for Source of Income.

Sub Flows: Not Achievable.

Sub cases: Achievable.  

Data Propagation:  

·         Is the requirement to not show /save unwanted data to the “Task” or to show / save as much data as required to perform the “Task”.  Example: To perform an Assessment of a loan, Assement officer should know about Loan Details / Income and expenditure details, but not required to know about applicant’s personal details.

Sub Flows: Not Achievable.

Sub cases: Achievable.  Using Data Propagation, we can select the data properties to be copied into sub cases.

·         Is the requirement not to have stale data while performing the “Task”

Sub Flows: Achievable.

Sub cases: Not Achievable.  We need to write custom code to fetch data from parent to child case.

Specialization:

·         Is the requirement to Specialize flow rules

Sub Flows: Achievable.

Sub cases: Not Achievable.  

·         Is the requirement to Specialize Class rules

Sub Flows: Not Achievable.

Sub cases: Achievable.  

Storage:

·         Is the requirement to store the details of the “Task” in separate table. Example: Store all Underwritten claims to a different table

Sub Flows: Not Achievable.

Sub cases: Achievable.

Security:

·         Is the requirement to have different secured strategies for the “Task”.

Sub Flows: Not Achievable.

Sub cases: Achievable.

Reporting:

·         Is the requirement to have fine grain report for the “Task”

Sub Flows: Not Achievable.

Sub cases: Achievable.

Policy Override:

·         Is the requirement to suspend only the “Task”, when certain conditions are met

Sub Flows: Not Achievable.

Sub cases: Achievable.

·         Is the requirement to suspend not only  the “Task” but also the origination flow, when certain conditions are met

Sub Flows: Achievable.

Sub cases: Not Achievable.

If we can have each box ticked off and then a simple math would help us decide which one should our design have, Sub Case or Sub Flows.

Hope the above article is covers most of the required stuff. Please leave a comment with your practical experiences on how useful this article was and also any thing needs further explanations. 

Feedback's are welcomed in the form of comments.

Vamshi