Build a request type

A request template (request type) is everything about one kind of request: the form staff fill in, the document approvers read and print, the chain of approvals it goes through, and who files and receives the finished record. This page walks through building and changing one.

Open Administration › Request Templates. You need view_request_types to see them, add_request_types to create, and edit_request_types or manage_request_templates to change them. The hospital's catalogue (leave, finance, procurement, audit and more, each with a code such as fin-req-001) is already loaded; most of the time you will adjust an existing template rather than start from nothing.

Find a template

1. Search by name, code or description.
2. Category and Status filters.
3. New request type. Start a new one from scratch.

A template's page

1. Edit opens the editor. Next to it: New request of this type, Deactivate / Activate and Delete.
2. Submitter view (the form with sample values), Approver view (the printed document) and Approval chain. Nothing here is saved.
3. Summary: status, code, category, reference pattern, who can submit, number of form fields and approval steps.
4. Open requests of this type, with a link to see them.

Deactivate hides the template from submitters; requests already made are not affected. Delete is offered only when no requests of the type are open, and a type that already has requests can only be deactivated.

The editor

The editor has five tabs over one draft: Details, Form, Template, Approvals and Preview. Nothing is stored until you select Save (stay in the editor) or Save & close. A red dot on a tab means a problem that blocks saving; an amber dot is a warning. When you save with problems, a list at the top takes you to each one. Leaving with unsaved changes asks you to confirm.

1. Details

1. Basics. Name, Code (locked once saved, because reference numbers and the seed use it), Category, Icon, Active, Description (shown on the type card) and Help text for submitters (shown above the form).
2. Reference numbers. The Pattern every request of this type is numbered from. Select a token to add it: {code}, {unit}, {YYYY}, {YY}, {MM}, {DD}, {seq}, {seq:5}. Numbering restarts whenever a date token changes. An example is shown underneath. The hospital uses {code}/{YYYY}/{seq:4}.
3. Who can submit. Limit to units and Limit to roles. Leave both empty to allow everyone with the “Add requests” permission.
4. Registry access. Units with access can open every request of this type, in progress or closed, from Requests › Registry desk. Shared across the submitting unit lets everyone in the submitter's unit open it; leave it off for confidential types.
5. Payment follows approval. Pick a Voucher type and every approved request of this type waits in the Accounts Queue until Finance raises that voucher against it. The requester sees the payment reach “Disbursed”.
6. Registries. One switch per registry office: which registries file the finished record, approved or rejected. All are on by default. Each one switched on is notified and prints its own copy.
7. Dispatch on approval. Who receives the signed record when the request is finally approved (see below).
8. Save. Also Save & close and Cancel.

Dispatch on approval

When a request is finally approved, the signed record with its comments and approval trail goes to the registries switched on above, and to the offices you choose here. Each office is notified and prints its own copy.

Use the organisation’s default offices

On: the offices in the system setting dispatch.default_group_codes (the CMD Secretary Office, CMAC Office and DA Office). Off: choose Offices for this type.

Also the originator’s head of unit and head of department

Formally notify the requester's HOU and HOD of the decision.

People named on the form who also receive it

Tick a “Person” field on the form to send the record to whoever the submitter picked there.

The originator always receives the record. Payment-linked types also go to Finance / Accounts. Rejected requests go back to the originator and the approvers, and are filed with the registries.

2. Form

1. Add a field. Pick a field type to add it to the form.
2. Build / Preview. Switch between arranging fields and trying the form as a submitter would.
3. The fields, in the order they appear. Drag to reorder. Select a field to edit its settings; badges show Required, Half width, Conditional and Request amount.

Field types:

Each field's settings are grouped as Basics (label, key, help text, placeholder, required, width, default value), settings for its type (options, currency, columns…), Validation and Visibility (Only show when… another field has a given value). An items table or amount can be marked Use as the request amount; only one field per form can be. That amount drives payment vouchers and the “critical amount” flag.

3. Template (the printed document)

The template is the official document approvers read and registries print. It is edited in a rich-text editor with the letterhead and page set up around it.

1. Edit / Preview. Preview fills the document with sample values.
2. Apply official layout. Replaces the body, letterhead, footer and page setup with the hospital's official layout: logo letterhead, watermark, verification QR code and status stamp. Your current layout is lost unless you leave without saving. (Insert starter layout appears instead when the body is empty.)
3. Insert variable. Adds a placeholder filled from the request: form fields, the request (reference, dates, status), the submitter, their head of unit, approvals and the organisation.
4. Insert block. Adds a ready-made part: Form fields (a table of every answer), an items table, Approval chain (each step with who decided, when and their signature), a signature (submitter, head of unit or a given step's approver), Attachments, Distribution list and Page break.
5. Page setup. Branding & security (plain, classic or official style; accent colours; watermark; verification QR code; status stamp), Letterhead (lines, image, alignment), Footer (text, page numbers) and Page (size, orientation, margins).

The logo on the letterhead and watermark is the organisation logo, which is uploaded by the ICT team.

4. Approvals (the chain)

The chain is an ordered list of steps. Each step either recommends (the chain continues either way, carrying the note) or approves (a rejection ends it). Steps run in order and the last step must be an approval.

1. Step name. What approvers and the printed record call it, for example “L-1 · Head of Department”.
2. Action. Recommend or Approve.
3. Assigned to. Who receives the step (see the rules below). “Will be assigned to” at the bottom of the card sums it up.
4. Decision wording. The words on the buttons, the timeline and the printed record, such as Treat / Don't Treat or Authorized / Not Authorized, or your own. The decision is still stored as approved / rejected, so reports are unaffected.
5. Chain settings. Stop on “Do not recommend” (a negative recommendation rejects at once instead of passing it on) and Require a supporting file (the submitter must attach at least one document).

Each step card also has Copy decisions to (optional) (the heads of these offices are told of every decision at this step and may open the item; for example the DA hears the CMD's decision), Expected turnaround (hours, optional), and, on recommend steps, Offer “Partially recommend” (used by the Audit HOD). The ⋯ menu moves, duplicates or removes a step; you can also drag steps. Add step is at the bottom.

Who a step goes to

Assignees are worked out when the request is submitted, and again as each step opens. If a step cannot be assigned (no head, nobody with the role), the submitter sees why before anything is created, so fix the unit tree or the chain.

Comments, signatures and returns

Three rules apply to every chain and are set in Settings › Variables, not per template:

approvals.require_comment

On (the hospital's choice): approvers must write a comment to approve, reject or recommend.

approvals.require_signature

On: approving or recommending needs a signature on the approver's profile. Switch it on only once every approver has uploaded one.

approvals.allow_return

On: approvers may return a request to its originator for correction. It is resubmitted under the same reference and starts again from the first level.

5. Preview

Fill in a few fields on the left as a submitter; the document on the right shows what approvers will see, using your values and sample data for the rest. Use it before every save.

Build a new request type, start to finish

1. Select New request type.
2. Details: name, code, category, description and help text. Set the reference pattern. Limit who can submit if needed.
3. Form: add the fields, starting with a section heading. Mark required fields. If it involves money, add an items table or amount and mark it as the request amount.
4. Template: select Apply official layout, then adjust the body.
5. Approvals: add the steps in order. For a standard administrative request: L-1 Head of the submitter's unit, then the DA (head of ADMIN), then the CMD (head of EXEC).
6. Details again: set registry access, registries, dispatch and, if it leads to a payment, the voucher type.
7. Preview, then Save & close.
8. Test it: sign in as a test person and submit one.

Related

• Request Templates reference
• Approval workflows (for vouchers and memos)
• Registry offices
• Submit a request and Approve, return or reject