Skip to Content

How I went about creating a sample warranty claims process using Galaxy

I had the following requirements for building the warranty claims process:


At the generic level these processes are initiated by Customers  via a request to Sales Agent in the Market Unit. The Sales Agent sends the request to the Claim Agent in the Claims Department. The claim agent approves the claim and initiates the essential interactions (sub processes) with the business partners like Manufacturer, Forwarder and others to finalize the claim.


I implemented this in Galaxy as the following process and subprocess flows:


Note: For clarity, I divided the process into two parts.


Process Part 1:



Process Part 2:





Steps in the implementation:


  • Customer is not shown in the process as he/she is not part of the Organisation. He/She enters data in a Claim Request application and on submission of the data, the Warranty Claims Process kicks-off. I have used a WebDynPro view to capture the data and the on-click event of the submit button initiates the Claim Process and passes the Claim Request data to the process using a Web Service.
  • This request comes to a Sales Agent who reviews the Claim for its completeness and if it is complete, forwards it to the Claims Agent. “Review Claim Request” is a human activity where the Sales Agent can modify the Claim Request if needed and add comments. “Validate Claim” is a mapping where I used rules to check for validation of the Claim Request. I created a ruleset in the process that checks for simple validation like all the data is entered and that the product was purchased in the last one year. As these rules don’t change very often and are not complex for maintenance, I have modeled rules within the process.
  • Claims Agent creates the Claim data from the Claim Request and enters the defective parts that are responsible for the problem. “Create and Update Claim” is the human activity where he/she does this. Rules are used in the “Analyze Claim” step to analyze the Claim and determine who the Liable Party is. As these rules can change frequently and can be complex, these are modeled using Rules Composer. The Ruleset is exposed as a webservice and is called from the Process using an Automated Activity.
  • I modeled Assess Liability as a subprocess as the Manufacturer/Forwarder need not be part of the Organisation. In the Subprocess, there is a Human Activity “Investigate Claim” which allows the Liable Party to look and modify the Claim if needed, and then Rules are invoked in the “Evaluate Claim” step to determine the Claim amount based on the defective parts, repair charges etc. For the same reasons as above, rules for this are modeled using Rules Composer and invoked using an Automated Activity.
  • Once the cost of the Claim is determined, this data is passed back to the Claims Agent for approval of the amount.
  • Once the claim is approved by the agent, rest of the process involves picking up the product from the Customer, issuing Goods Receipt and Crediting the amount. To simplify the process, all these steps are modeled as place holders in the sample process.
Be the first to leave a comment
You must be Logged on to comment or reply to a post.