Setting Fulfilra up
You will get a working catalog in about ten minutes, name the people who run it, connect it to a Jira project, and know where to look when something is wrong.
For: Jira site administrators. Fulfilra asks Jira who administers the site on every single screen load, so this is the same list of people Jira already trusts. There is nothing to grant and nothing that can drift.
Where the settings are
Jira settings → Apps → Fulfilra. Seven tabs. Jira renders this page only for site administrators, and Fulfilra re-checks that on every action behind it, so an ordinary user who finds the URL gets nothing.
1. Setup
Four steps, in the order that gets you to a working product fastest. Completion is worked out from your actual configuration, not remembered — so if you do something from another tab, this tab notices.
“Name your agents” has no Skip button, and that is deliberate.The moment Fulfilra is installed, every licensed user on your site can raise a request. Nobody can work one until you name an agent. An install where that never happens looks exactly like a broken product: a full catalog, requests piling up, and a queue nobody touches. Fulfilra will not let you walk past it.
2. Team
Three roles, and only two of them are stored here.
| Role | Who has it | How |
|---|---|---|
| Requester | Every licensed user of the site | Automatic. No row, no invitation, no provisioning |
| Agent | People who work requests | You grant it here |
| Approver | People who can be named on an approval step | You grant it here |
| Administrator | Whoever administers the Jira site | Derived from Jira, every time. Not stored, not editable |
Pick a person from the Jira user picker, pick a role, press Grant.
Why administrators are not a list you edit. If Fulfilra kept its own list of administrators, that list would eventually disagree with Jira's — somebody leaves, they lose Jira admin, and they keep Fulfilra admin. Asking Jira on every invocation costs a fraction of a second and cannot go stale.
Why not Jira groups for agents and approvers? Because an approval is a named person's decision. If approvers were a group, an unrelated administrator renaming or re-membering that group would silently change who can approve your company's spending, with nothing in Fulfilra recording that it happened.
Deactivated people are flagged. Fulfilra reads account status from Atlassian, so somebody who has left shows as Deactivated in Atlassian here — and any approval still waiting on them is listed for you. Nothing is reassigned automatically; change the request type's approval step and the next request goes to the right person.
3. Templates
The fastest route to a real catalog. Two starter packs:
- IT service desk — 11 request types: general help, new starter setup, leaver deprovisioning, hardware, software and licences, application access, password reset, VPN and remote access, shared mailboxes, mobile and SIM, file and email restore.
- HR & people — 9 request types: ask HR, onboarding, employment letters, leave, flexible working, payroll queries, personal details changes, training and development, workplace adjustments.
Each type arrives with its form written. Install a pack, then edit what does not fit — several carry starter option lists (departments, offices) explicitly marked for you to replace.
The Free edition includes one pack; the full 20-template library and the second pack are part of Teams. Installing a pack twice is safe: it fills in anything missing and leaves what you have alone.
4. Catalog
Categories are the headings requesters see. Request types are the forms.
Each type shows a state:
- Published — visible in the catalog.
- Archived — hidden from requesters. Existing requests are untouched; archiving is how you retire a form without breaking its history.
- Silent approvals — a warning. See below.
The “Silent approvals” warning
If a request type requires approval but does not create a Jira issue, its approvers are told only inside Fulfilra. No email is sent, because a Forge app has no mail transport of its own — Jira's email is the only one available, and it needs an issue to hang on.
That means an approval raised on Friday afternoon may not be noticed until Monday, and nothing anywhere looks broken in the meantime. It is the single most damaging configuration available in this product, which is why creating an approval-bearing type turns issue creation on by default and why the catalog labels any type where you have turned it off.
If you choose it deliberately — for something confidential that should not appear on a board — make sure the approvers know to check the app.
Editing a type
Settings. Name, category, whether it needs approval, whether it creates a Jira issue, and whether it is archived.
Form fields. Each field has a key (stable, used in storage), a label (what the requester reads), a type, and whether it is required. Select and multiselect fields take a comma-separated option list.
Editing is safe in one direction and blocked in the other: you can rename a label, change requiredness and add fields freely, but a field that already has submitted answers cannot be deleted. Fulfilra refuses and tells you which one — deleting it would orphan the answers on every historical request.
Approval steps. Up to three, decided in order. Each names one person, who must already hold the approver role — grant it on the Team tab first. The Free edition allows one step per type; Teams allows three.
Ask for approval only where a “no” is genuinely possible. A step that is always approved adds a day to every request and teaches everyone to click through without reading.
5. Jira
Project for new issues. Pick one. Every request whose type creates an issue is filed here the moment it is submitted — not in five minutes, not on a queue.
This choice does more than route work. Notification by email is only possible through a linked issue, so a site with no project set is a site where nothing reaches anybody by email. A JSM project is the usual choice; any project works.
When an issue moves in Jira. Mapping is by Jira status category — To Do, In Progress, Done — not by status name. Rename a status on a board and this keeps working, which is the point: names change constantly and categories do not.
The defaults:
| Category | Does | Why |
|---|---|---|
| To Do (new) | Nothing | An issue dragged back to To Do is usually a board being tidied, not a request being un-started |
| In progress | Moves the request to In progress | |
| Done | Moves the request to Resolved | Not Closed — closure is the requester's to give |
You can change these. What you cannot do is map a category to a terminal status: Fulfilra refuses to save a mapping that would let Jira approve, reject, close or cancel a request, and says so rather than accepting it and silently ignoring every event. Those decisions stay with people.
Sync failures. Events Jira sent that could not be applied — an issue moving after its request was closed, an unrecognised status category. This list is normally empty. When it is not, each row names what arrived and why it was refused. Nothing is dropped silently.
6. Reporting
How many requests, how many open, mean time to resolve over the last 30 days, and the breakdown by status. Part of the Teamsedition; on Free the tab explains what it shows.
The number worth watching is the Waiting on information from customer count. A large one usually means requests that have quietly died waiting on a reply and need closing, not more agents.
7. Database
Fulfilra's data lives in a database that belongs to your Jira site alone, provisioned by Atlassian inside your tenancy. No other customer's data is in it, and none of yours leaves it.
The schema is built when the app installs and re-checked hourly. Run schema migrations now is the manual path, for the rare case where a screen reports a missing table right after installation — normally you never need this tab.
Editions
Derived from your Atlassian licence on every screen load, never stored.
| Capability | Free | Teams |
|---|---|---|
| Request types, requests, approvals | Unlimited | Unlimited |
| Starter packs | 1 | Both |
| Template library (20 templates) | — | Yes |
| Approval steps per type | 1 | 3 |
| Reporting | — | Yes |
A licence that lapses drops the site to Free. Every request stays exactly where it is and every screen keeps working — you get a smaller product, not a locked one.
When something is wrong
| What you see | What it means | What to do |
|---|---|---|
| Requests pile up, nobody works them | No agent named | Team tab. This is the failure the Setup tab refuses to let you skip |
| A screen reports a missing table | Schema not built yet, just after install | Database tab → Run schema migrations. Or wait an hour |
| Requests submit, no Jira issue | No project set, or Jira refused | Jira tab. The requester's confirmation quotes Jira's own error |
| Approvers say they hear nothing | The type creates no issue — “Silent approvals” | Catalog tab: turn issue creation on, or tell approvers to watch the app |
| Board moves do not reach Fulfilra | Category mapped to “Do nothing”, or the move is one Jira may not make | Jira tab: check the mapping, then the sync failures list |
| An approval waits on someone who left | They are deactivated in Atlassian | Team tab shows it; edit the type's approval step |
| Everything says “Free edition” on a paid site | You are on a development install | Licences only exist in production |
What Fulfilra deliberately does not do
Worth knowing before somebody asks you for it.
- No email of its own. It runs entirely inside Atlassian and sends nothing outward; Jira's notifications on a linked issue are the only email, and the in-app inbox is the guaranteed one.
- No access for people without a Jira licence. Everyone who raises a request is a licensed user of your site.
- No file upload in the request form. Attachments go on the Jira issue, and are visible to anyone who can browse that project.
- No approval delegation. Change the named approver instead.
- No cross-site view. One installation, one database, one site.
Install it, and raise a request five minutes later
Free edition, no card, no separate account. Everyone on your Jira site can raise a request the moment it is installed.