Requests
Requests is where a hardware ask becomes a ticket. Somebody raises it from the catalogue, an approver decides, and the machine is allocated from stock. Every step is recorded against the ticket.
- For
- A hardware ask becomes a ticket: raised from the catalogue, approved, then allocated from stock.
- Will not
- Allocate and close in one write. The ticket is closed first, then the asset assigned, so a failed assignment leaves a fulfilled ticket and a machine still on the shelf. It is visible on the same screen and fixed by one manual assignment.
- Writes
- The ticket, its state and its activity. A request never moves backwards through its states.
What you are looking at
Requests opens on the queue. A ticket is a request for a catalog item, and it carries its own state from the moment it is raised until it is fulfilled or closed.
The segmented control at the top left is the scope: Queue, All or Closed. Queue is what still needs somebody to act on it. All is everything ever raised. Closed is the terminal states: Fulfilled, Cancelled and Rejected. Changing scope reloads the list.
New Request on the right raises a ticket. Clicking a row opens the ticket detail, which is where every lifecycle action lives.
Raising a request
A request is a catalog item plus the answers its questions ask for. The catalogue is defined in Admin; here you pick from it.
Pick the item
The Item picker lists every catalog item by title, with Choose… as the empty state. The item’s summary appears under the picker when it has one.
Answer the questions
Each item carries its own questions, and each question renders by its type: a single line of text, a longer one, a number, a fixed choice, an asset type, or a date. A choice or asset-type question starts at Choose….
Name who it is for
Requested for is a search over the directory. Type into Search directory… and matching people appear with their name and email; picking one fills the field. Leave it empty and the request is not tied to a named holder.
Set priority and a date
Priority is one of the ticket priorities, defaulting to Medium. Needed by a date is off by default; turn it on and a date picker appears.
Submit
Submit Request creates the ticket and submits it in one action, which routes it to approval. The button is disabled until an item is chosen.
If a required question is left blank, the sheet does not close. It shows Please answer: followed by the labels of the questions still missing, and stays open so you can fill them in.
Reading a ticket
Open a row and you get the ticket: its header, the requester context, the actions available in its current state, its answers, its history and its notes.
REQUESTER CONTEXT is the card worth reading before you decide. It describes what the requester already holds: their current devices, each with its age in months, warranty end, purchase price and status. The line above the devices is a short narrative of the request, produced on the Mac.
REQUEST DETAILS lists the answers to the item’s questions, by label. HISTORY is the activity trail: created, submitted, approved, rejected, fulfilled, cancelled, commented, state changed, on hold, resumed, each with a timestamp. NOTES is the comment thread, and each note is either internal or marked visible to requester.
The lifecycle
A ticket moves through a fixed set of states. The actions available on the detail view are exactly the transitions that are legal from where the ticket is now.
- Pending Approval. Approve moves it on. Reject opens a prompt for an optional reason and ends it there.
- Approved. Start Fulfillment picks it up.
- In Fulfillment. Fulfill from Stock allocates a machine. Awaiting Stock parks it until one is available.
- Awaiting Stock. Back to Fulfillment returns it to the allocation step.
- On Hold. Resume returns it to where it was.
Hold and Cancel sit on the right of the actions row for any ticket that is not terminal and not already fulfilled. Hold is not offered while the ticket is already on hold.
Fulfilling from stock
Fulfillment allocates an in-stock asset to the requester. The list you choose from is filtered to the ticket's catalog type.
Picking a row allocates that machine and closes the ticket. The asset is assigned to the requester, its status becomes active, and it is linked back to the ticket that acquired it. The new holder’s acknowledgement is cleared, because a new holder acknowledges for themselves.
If nothing matches, the sheet says No matching in-stock assets. and suggests marking the request Awaiting Stock until one is available. That is the intended path, not a dead end.
When fulfillment goes wrong
Allocating an asset and closing the ticket are two separate writes, and the order they happen in is deliberate.
The ticket is closed first, then the asset is assigned. If the assignment fails, you are left with a ticket marked fulfilled and an asset that was not handed over. That failure is visible on the screen you are already looking at, and fixing it is one manual assignment.
The other order was tried and rejected. Assigning first meant a ticket that could not be closed, because it had been put on hold or cancelled while the sheet was open, left the asset assigned and active with the ticket still open and still fulfillable. The operator would fulfil again, a second machine would go out against one request, and the audit trail would show both assignments as legitimate. Closing first makes the failure harmless instead of silent.
Notes on a ticket
Every ticket has a comment thread. Each note is either internal or visible to the requester, and the choice is made when you write it.
Type into Add a note… and press Add. The Requester toggle next to the field decides whether the note is visible to the requester or internal only. Notes marked visible carry a · visible to requester label in the thread, so the audience of every note is on screen.
Notes are attributed to the author and timestamped. They sit alongside the activity trail, which is written by the lifecycle actions rather than by hand.
Where requests come from
Requests is the admin side of a flow that also runs on the companion app. The catalogue, the directory and the approval rules are all defined in Admin.
The items you can request are the catalog items defined in Admin, and the questions each item asks are defined there too. The people you can request for come from the directory. The approval context card reads the asset register, so what it shows about a requester is what the register currently holds for them.
Fulfillment writes to the asset register through the same path as a manual assignment, so the audit trail on the asset is correct regardless of how the machine reached its holder. See Assets for the register itself.