> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/health/v1.5/hcm-product-suite/health-products/digit-hcm-app/user-manual/common-functions/raising-complaints.md). # Raising Complaints An illustrative guide to using the Complaints Module (Mobile) Users can file a complaint using the HCM app. There are a few assumptions: * Not all complaints will be logged using the complaints module. Users may prefer raising complaints on WhatsApp groups/calls, and may not be registered in the system. * Complaints are most likely to be logged by users on behalf of other users (Most common use case: Supervisors raising complaints on behalf of users). ## User Roles
User RoleScope of ActionRole Description
RegistrarCreate and view complaints.Registrars can raise technical complaints on the application
Field Supervisor

Create and view complaints.

Assist the frontline teams and raise the issues communicated by them on the application
Supervisor

a. Create and view complaints.

b. Resolve complaints, re-assign complaints back to the helpdesk, and reject complaints.

Monitor the overall campaign and provide assistance for the issues raised by the field teams
Helpdesk user

a. Create and view complaints.

b. Resolve complaints, assign complaints, and reject complaints.

Helpdesk users are the support team established to provide assistance throughout the campaign.
## Users Raising Complaints After logging into the application, the user lands on this screen which displays daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations. The action buttons related to the beneficiary are present, which include: * Beneficiaries * View reports * Sync data * Call supervisor * Complaints ### Complaints When the user clicks on the complaints, she is navigated to the “My Complaints” screen, which consists of two actions: * File a complaint (primary action): Clicking on this must open the complaint type screen. * View previously logged complaints. ![](https://content.gitbook.com/content/GYQEda2SOh4goA6Ee2d2/blobs/94xvHDbeOmNp77l4XQGh/IMG_20230513_234148.jpg) ### File Complaint Workflow #### Complaint Type When the user clicks on file a complaint, the complaint type screen appears. The user must select the type of complaint from the list, which must be configurable (to be configured during implementation as per program requirements). There is a ‘Next’ button at the bottom of the screen, clicking on which, the user is navigated to the complaint details screen. ![](https://content.gitbook.com/content/GYQEda2SOh4goA6Ee2d2/blobs/jBIHF4GBQaMHkSftURQw/IMG_20230513_233907.jpg) #### Complaint Details Once the user has selected the type of complaint and clicked on ‘Next’, this screen appears, where they need to provide the complaint details. The date field is auto-captured by the system, which must be non-editable. The administrative area is also auto-captured but it is editable. It is editable in case the user is creating the complaint on someone’s behalf. The dropdown displays a list of boundaries that are assigned to the user. The user needs to select whether she is raising a complaint for herself or on behalf of another user. If the user wants to raise a complaint for herself, then she must provide the following details: 1. Name (must be populated if already available in the user’s profile else must be blank). 2. Contact number (must be populated if already available in the user’s profile else must be blank). 3. Supervisor’s name and contact number. If the complaint is raised on behalf of another user, then her details must be captured in the above fields. The user has the option to upload images describing the issue along with a text-based description. If the user wants to change the type of complaint, they can click on the ‘Back’ button and return to the previous screen. After filling in all the details, the user needs to click on the ‘Submit’ button to file the complaint. ![](https://content.gitbook.com/content/GYQEda2SOh4goA6Ee2d2/blobs/2xxNDLr9C56zlnpFTsBb/IMG_20230513_233934.jpg)
### Confirmation Screen When the user clicks on the submit button after providing all the complaint details, the confirmation screen appears, which provides information on whether the complaint has been submitted or not. * If the complaint has been submitted, then it must show the message to sync the data for generating the complaint number. There must be a back to home button below the message. When the user clicks on it, she must be navigated to the home screen. * If the complaint has not been submitted, then there must be two buttons available; Retry and Back to Home. ![](https://content.gitbook.com/content/GYQEda2SOh4goA6Ee2d2/blobs/HMVDTP8pvGzdePgslwXG/IMG_20230513_234003.jpg) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.digit.org/health/v1.5/hcm-product-suite/health-products/digit-hcm-app/user-manual/common-functions/raising-complaints.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.