Giving Your CFO Jira Access Without the Admin Keys

The email usually arrives in the CFO's second month: "Could I get access to Jira? I'd like to see where the hours are going." It's a completely reasonable request. The worklogs in Jira are the raw material of every cost number the agency has; asking finance to run margins without them is asking someone to audit a warehouse through the letterbox.

What happens next is where agencies go wrong in one of two directions. Either the request stalls — IT hesitates, the delivery team bristles slightly, and the CFO goes back to monthly CSV exports. Or the request succeeds too well: the CFO gets an account with sweeping project access (sometimes, in smaller shops, the actual admin credentials), logs in twice, finds a wall of boards and workflow states, and quietly goes back to monthly CSV exports anyway.

Both outcomes fail for the same reason: they treat the question as access to Jira when it's really access to answers. This piece is about giving each role the answers — without handing anyone keys they'll never use.

What finance actually needs from Jira

Strip the request down and the CFO needs a small, specific set of things, none of which is "operate Jira":

• Worklogs — who spent time, on what, when — because hours multiplied by real employee cost is the cost side of every project.
• Estimates and structure — what was planned, at what role, in which engagement — because variance against plan is where margin problems announce themselves early.
• Continuity — this month's picture during this month, not three weeks after close. I've written about the queries a CFO should be running; their value is in being run weekly, not quarterly.

Notice what's absent: creating tickets, editing workflows, administering users, changing anything at all. Finance's relationship to Jira is entirely read-shaped. That single observation should drive the whole access design — and it's why the admin-account shortcut is wrong on its face. Not because anyone distrusts the CFO; because handing someone write-everything keys for a read-only job is bad architecture in both directions. The CFO carries risk they never asked for, and the instance carries a high-privilege account whose owner has no reason to learn Jira's guardrails.

The three levels of access, and who needs which

In practice there are three sane shapes of finance-side access, in ascending order of usefulness.

Level 1: a scoped read-only account. A Jira licence with browse-projects and view-worklog permission on the relevant projects, nothing else. Cheap, honest, and better than credentials borrowed from an engineer. Its limitation isn't permission — it's translation. Jira renders tickets and boards, not costs and margins. A CFO at this level can verify but can't really monitor; every question still routes through an export and a spreadsheet.

Level 2: dashboards and filters built for finance. Someone — usually a sympathetic delivery lead — builds saved JQL filters and a dashboard: hours by project this month, tickets over estimate, unestimated work in progress. Genuinely useful, and where many agencies settle. Two costs: the dashboards show hours, never money, because money (rates, salaries, overhead) doesn't belong inside Jira, and shouldn't be put there for exactly the reason you're reading this section — anyone with project access could see it. And the dashboards are maintained by hand, which means they decay.

Level 3: a financial layer that reads Jira for them. A system connects to Jira through its own scoped, read-only integration — how that connection is made matters — joins worklogs with the cost data that lives outside Jira, and gives finance a login of its own. The CFO stops logging into Jira at all, not because access was denied but because the answers moved somewhere better. Jira keeps exactly one integration account to audit, instead of a person-shaped account with person-shaped risks.

The part people miss: this isn't only about the CFO

Here's where the conversation usually gets framed badly — as if the point were locking things away from everyone but finance. The more useful framing is the opposite: every role gets a first-class view, in the unit that fits the job.

The CFO's unit is money: margin by engagement, cost variance, the real number after overhead. A project manager's unit is hours: burn against estimate, role drift, scope creep on their own projects — the things a PM can actually act on this week. In Saldo this is the manager view: the PM watches their project continuously, in hours, with full visibility of where time is going — while the money translation (what each person costs, what the engagement earns) stays with the roles that set prices and salaries. I've written about why that split makes teams healthier, not more opaque — the short version is that people do their best work watching metrics they control, and hours are the metric a PM controls.

So the finished architecture isn't "CFO sees everything, everyone else sees nothing". It's closer to:

• Delivery team — Jira, unchanged. Nothing new to learn, nothing watching over their shoulder that wasn't there before.
• Project managers — the financial layer in hours: continuous, project-scoped, actionable.
• Finance and owners — the same layer in money: margins, costs, portfolio.
• Jira admins — one read-only integration account to audit, and no finance-shaped licences to manage.

Same worklogs underneath every view. Nobody reconciles anything, because everyone is reading the same source translated into their own unit.

How to set it up this quarter

If your CFO is currently working from exports, the path is short:

1. Create a scoped read-only account now — it costs an afternoon and ends the credential-borrowing immediately. Browse and view-worklog on client projects; nothing more.
2. Decide where money lives. Rates, salaries and overhead do not go into Jira fields — they go into whatever layer sits above it, with its own access control.
3. Give the PMs their hours view in the same move. If you only wire up the CFO, you've built a periscope; wire up the managers too, and you've built an operating rhythm. The PM who can see burn-against-estimate on Tuesday raises the flag on Tuesday — not at month-end when it's already a loss surfacing too late.
4. Retire the exports. If anyone still needs a monthly CSV after this, something upstream isn't finished.

The CFO's request was never really about Jira. It was about seeing the agency's cost engine while it runs — and the PMs deserve the same sight-line in their own unit. If you'd like to see what that looks like on your actual projects, the 15-minute demo runs on your real Jira data — read-only, no admin keys required, which is rather the point.