Fulfilra
Workflows

A request, end to end

One request followed from the moment somebody needs something to the moment they agree it is done — and then the rules underneath it.

The request, step by step

  1. Priya needs a laptop

    She opens Fulfilra from Jira's Apps menu — no signup, no second password — picks Hardware request from the catalog, and fills in the form. It asks what she needs, who it is for, when, and why.

  2. Submitted, and filed in Jira in the same moment

    She gets two identifiers: REQ-48 for the request andITSM-212 for the Jira issue that already exists. Because the type needs approval, the request is Pending approval and stops there.

  3. Jade is asked

    Jade is step 1 on this type. The request appears in her Approvals tab marked Your turn, and in her inbox. She reads Priya's justification and approves with a note about the budget — a note Priya does not see, because it is commentary for the business.

  4. Mei picks it up

    It reaches the queue as Approved. Mei presses Start work; the request assigns itself to her and Priya is told work has started. Mei orders the machine on the Jira board her team already lives in.

  5. A question, and an answer

    Mei needs the office address, so she comments and setsWaiting on information from customer. Priya is notified, replies, and Mei resumes. Priya was never notified about the internal note Mei left for her colleague about the supplier being slow.

  6. Done, and agreed

    Mei drags the issue to Done on her board. Fulfilra moves the request toResolved and tells Priya. Priya checks the laptop, and presses Close. Had it not been right, she could have reopened it — with the whole history intact.

The lifecycle

Ten statuses, and who may move between them

The matrix is fixed. Every status change goes through it — a button, an approval, or a Jira board — and writes exactly one history row.

Status transitions, and who may make each
FromToWho may
SubmittedPending approvalAutomatic, at submission
SubmittedIn progressAgent, admin, Jira board
Pending approvalApproved / RejectedThe named approver, via the approval engine
ApprovedIn progressAgent, admin, Jira board
In progressWaiting on customerAgent, admin
Waiting on customerIn progressAgent, admin, the requester, Jira board
In progressSuspendedAgent, admin
In progressResolvedAgent, admin, Jira board
ResolvedClosedThe requester, agent, admin
ResolvedIn progress (reopen)The requester, agent, admin, Jira board
Submitted / Pending approval / ApprovedCancelledThe requester, admin

The absences matter more than the entries.

Nothing leaves Pending approval except through the approval engine — a Jira transition past an approval gate would be an authorisation bypass wearing an integration's clothes. Nothing reaches Closed,Cancelled or Rejected from a board, because an integration should not be able to end somebody's request. And nothing moves at all once a request is finished: a board moving afterwards is recorded for an administrator to look at, not applied silently.

Same request, four viewpoints

Everybody sees what is theirs to see

A request showing its details, approvals, comments and full history
The requester: their answers, the approvals, the conversation, the history.
An agent working a request, with transition buttons, public comments, an internal note and a comment mirrored from Jira
The agent: transitions, the assignee picker, internal notes, mirrored Jira comments.

A requester sees

Their own requests, only. Every answer they gave, which approval steps exist and how each went, public comments, and a history with the internal states left out.

A requester never sees

Anybody else's request. Internal notes between agents. An approver's private commentary — except a rejection's reason, which is theirs.

Agents and approvers see

Every request on the site, with every note. Approvers get the full queue read-only so they can put a decision in context.

The Jira half

What a board move does

Fulfilra maps Jira's three status categories — not status names, which teams rename constantly.

How a Jira issue category maps back to request status
Jira categoryDefaultWhy
To DoNothingAn issue dragged back is a board being tidied far more often than work being un-started
In ProgressIn progressWork has genuinely begun
DoneResolvedNot Closed — closure is the requester's to give

An administrator can change these, but not to a status Jira may never reach. Fulfilra refuses to save such a mapping and says why, rather than accepting it and ignoring every event.

Jira settings: the project for new issues and the status category mapping

See it on your own site

Install the Free edition and walk this whole workflow in about ten minutes.