This sample application is for store staff and MDriven developers who want to evaluate a complete complaint-handling workflow, including complaint decisions, customer communication, and operational follow-up.
Overview
The Store complaint handling sample is a complete application model with example data for a clothing store. It demonstrates how a store can record and follow a customer complaint from initial handling through decisions, product movement, reimbursement, credit, and closure.
Use it as a working reference when you need to build or extend a retail complaint process in MDriven. The sample includes both the application model and a database image with prepared users, messages, and complaint records.
For other ready-to-apply application models and data, see Documentation:Example Gist.
Download and open the sample
Download the complete database copy: File:StoreComplaintHandlingApp.zip.
The supplied database image includes the model and example data. Review the sample in a non-production environment before adapting it to your own application.
Included sample access
| Purpose | User name | Password |
|---|---|---|
| Store employee | john@acme.inc
|
123456
|
| System manager | admin@acme.inc
|
123456
|
| MDrivenServer log-on | a
|
123456
|
Important: These are credentials for the supplied sample. Change or replace them before using a copied solution in any environment that other people can access.
What you can do in the sample
The sample supports a complaint process in which staff can track the complaint itself, record decisions, communicate with the customer, and follow the financial and product consequences of the decision.
Follow a complaint from start to finish
For each complaint, staff can track:
- The complaint process's current state.
- The information that has reached the customer.
- Internal notes for staff.
- Customer chat, with QR-code access intended to make customer access easier.
- The location and handling of the complaint product, meaning the broken product associated with the complaint.
- A replacement product received from a supplier.
- An exchange product supplied by either the supplier or the store.
- Reimbursement to the customer.
- Reimbursement from the supplier to the store.
- Credit associated with the complaint.
For example, a customer can return a broken garment. Staff can record the complaint, add an internal note, communicate the current status to the customer, record whether the store or supplier makes the decision, and then track whether the outcome is an exchange, reimbursement, credit, or a combination of these.
Record decisions at the appropriate level
The sample distinguishes these decision points:
| Decision | What it records | Example |
|---|---|---|
| Store decision | The store's handling decision for the complaint. | The store agrees to exchange an item from its own stock. |
| Supplier decision | The supplier's decision or response. | The supplier approves a replacement product or reimburses the store. |
| Manager decision | A manager's decision in the complaint process. | A manager approves an outcome that requires management review. |
This separation lets the application reflect that a customer-facing store decision and a supplier response are not necessarily the same event.
Work across stores and users
The sample includes support for multiple stores, address information, a logo, user management, login handling, user rights, and a staff to-do list. These features provide a reference for applications where complaint work is assigned to staff and managed across more than one store.
Sample data
The database image contains:
- User-interface messages for all states in the complaint process.
- Two sample application users: a store employee and a system manager.
- 200 fake complaints in different handling states.
The prepared complaints let you inspect lists, summaries, messages, and state-dependent behavior without first entering a large data set yourself.
Implementation patterns for developers
This sample is useful when you want to study how a complex business process can be represented in a MDriven model and exposed through a user interface.
State-driven complaint handling
A state machine represents the current stage of an object in a process. The sample uses complex state-machine setups for complaint handling and binds information, including messages, to states. This makes it possible for the interface to show information appropriate to the complaint's current handling stage.
For example, a complaint in one handling state can have different customer-facing messaging than a complaint awaiting a supplier response.
If you need to inspect the states of an object in OCL, the oclGetStates operator returns the names of its current states. See Documentation:OCLOperators oclGetStates.
ViewModels and summaries
A ViewModel defines the data and actions presented to a user interface. The sample includes summary views and developer patterns intended to make the user interface easier to create:
- Derived attributes and associations that prepare information for presentation.
- Summary views for inspecting complaint-related information.
- Printing setup for a ViewModel.
- Image upload and display.
- AngularJS dynamic styling.
For example, a derived attribute can present complaint information in a form that a summary view can display without requiring each interface element to reconstruct the same information.
Automation and traceability
The sample demonstrates:
- Automatic event tracking.
- Automatic logging when states change.
- Server-side assignment of numbering.
- QR-code setup for linking to applications.
These patterns help make process changes traceable. For example, automatic logging can record that a complaint moved to a new state, while server-side numbering can assign the complaint number independently of the client interface.
When adapting server-side actions, use Documentation:Debugging MDrivenServer Serverside actions to investigate failures and executed work. If an action stores generated text such as an error message, ensure that the target string attribute is long enough or truncate the value as described in Documentation:String attribute overflowing.
Suggested evaluation walkthrough
Use the prepared data to evaluate the sample before changing the model:
- Download File:StoreComplaintHandlingApp.zip and open the supplied sample environment.
- Sign in as
john@acme.incto evaluate the employee experience. - Open complaints in different states and compare the displayed messages, internal notes, customer communication, and available follow-up information.
- Inspect complaints involving a store decision, supplier decision, or manager decision. Identify how the complaint product, replacement or exchange product, reimbursement, and credit are represented.
- Sign in as
admin@acme.incto review the management-oriented user and rights setup. - Inspect the model for state machines, state-bound messages, summary views, derived information, automatic logging, numbering, QR-code links, and printing configuration.
- Replace the sample users, passwords, fake data, messages, addresses, and branding before using the solution beyond evaluation.
Adapt the sample safely
When you use this sample as a starting point, keep the complaint process and its state-dependent messages aligned. A change to a state machine can affect the messages, automation, summaries, and actions associated with that state.
Test changes against complaints in several states rather than only against a newly created complaint. The supplied 200 fake complaints are intended to support this type of review.
If you change persistence-related aspects of the model or database, consult Documentation:Persistence.