Key concepts

Before the tutorial, five minutes on how Tollgate fits together. Tollgate is small on purpose, but a few things surprise people on a fresh Jira site (chiefly “why is my Portfolio blank?”). This page gives you the shape of the app, so nothing on screen is a mystery.

Every topic below has a deeper page elsewhere. This one is the map, with links into the detail.

Two surfaces: The project view and the portfolio view

Tollgate shows up in two places, and it helps to keep them straight from the start.

• The project view — a Tollgate tab on an individual project. One project, one investment.
• The portfolio view — a site-wide Tollgate Portfolio page under Apps. One row per investment.

The project view is where the work happens: you charter the investment, scope it, track its risks and decisions, and set its status. The portfolio view reads that data back across every project, side by side, grouped by theme. You’ll spend most of your time in the project view and present from either.

The project view (the Tollgate tab)

Open a software or business project and you’ll find Tollgate in the left sidebar. It stays out of Jira Service Management and Jira Product Discovery on purpose. Tollgate governs bounded investments, and those project types don’t suit it.

The Tollgate tab opens on the Investment Health dashboard, a read-only summary that stays at the top. The registers sit as a row of cards beneath it:

1. The Tollgate tab — where the whole per-project surface lives.
2. The SAM stage rail — which gate the investment is at (Commit → Run → Realise).
3. The business-case reminder — what you funded this for, kept in view.
4. The dashboard: five status cards — the read-only picture you present from.
5. The registers — one card each, listed below.

Register	What it holds
Business case	The investment thesis — problem, outcome, expected return — plus the decision authority and steering committee. Where an investment earns its name.
Work Packages	Business-level slices of scope, each with an owner, dates and a budget. Scope, cost and time all come from here.
Risks & opportunities	A register of risks, opportunities and materialised items.
Decisions	An append-only decision log.
Changes	Change requests, with an approval workflow.
Close-out	The close-out report — the business case’s bookend, recorded when the investment ends.
Realisation	The benefits-measurement window after delivery, through to the realisation verdict.

Note

The dashboard lands you first, and on a new project it’s nearly empty. That’s expected: it has nothing to compose yet. Add a business case and a work package, and the dashboard fills.

Work packages carry the scope and the budget

This is the one that catches people out, so it’s worth stating plainly. You set scope, cost and time in work packages, and you need at least one.

A work package is a business-level slice — “Checkout UX overhaul” or “Data migration” — not a Jira ticket. Each one has a budget (baseline / forecast / actual) and start/end dates. The dashboard computes its Cost, Schedule and Scope cards straight from your work packages. No work packages means nothing to compute those cards from, so they stay blank. Add one and they light up.

See Add work packages.

Risks, Decisions and Changes are registers in their own right

These three aren’t just notes on the dashboard — each is a first-class register with its own card and its own workflow:

• Risks — a live register on the risk / opportunity / materialised model, scored by impact and likelihood, each with a treatment.
• Decisions — an append-only log: you record decisions, never edit them away, so the audit trail holds.
• Changes — change requests that move through an approval workflow (raised → adjudicated), so scope changes are governed rather than silent.

Each register’s card carries its live edge — counts, plus attention chips such as materialised risks or changes awaiting a call. The dashboard’s Control Centre queues anything waiting on a person. The registers themselves are where the substance lives.

The dashboard

“The dashboard” is the Investment Health summary at the top of every project’s Tollgate tab. It’s read-only: it reflects what you enter on the registers and recomposes as they change. You never edit numbers on it directly. The two exceptions are Overall and Confidence, the cards you set by hand. The dashboard is presentation-grade, so you present from it live rather than exporting a deck.

The Tollgate Portfolio page repeats the idea at portfolio level: the same governance signals across the whole set of investments, rolled up by theme.

For the card-by-card walkthrough, see Read the Investment Health dashboard.

The portfolio view (and why it starts blank)

The Tollgate Portfolio page (under Apps → Tollgate Portfolio) rolls every project’s governance health into one investments table:

1. Find it under Apps — it’s a site-level page, not a project tab.
2. It’s driven by a Jira Plan (Premium) — pick the Plan whose projects you want to roll up.
3. Portfolio KPIs — total budget, outcome-confidence spread, health, materialised risks and pending decisions across the set.
4. One row per investment, grouped by theme, each with its health, budget-vs-forecast, outcome, confidence and stage.

Here’s the part that surprises people on a fresh site:

Why is my Portfolio blank?

Jira Plans drive the portfolio view, and it needs Jira Premium. Tollgate reads the projects inside an Advanced Roadmaps Plan and shows their governance health side by side — no Plan, no roll-up. On a brand-new Jira site with no Plans configured, the Portfolio has nothing to read and shows an empty state. It isn’t broken.

To populate it, create a Plan in Jira and add your projects as issue sources. Then pick that Plan from the plan-picker on the Portfolio page. See Connect a Jira Plan.

Without Premium, you can still run the entire governance workflow on any single project from its Tollgate tab. You just don’t get the cross-project roll-up.

Who can see what (access defaults)

Tollgate is an above-the-line surface: governance data your delivery teams don’t need to see. Access is deliberately narrow by default, and you widen it explicitly.

The portfolio view defaults to Jira admins only. To let a wider governance audience in, set a governance group — a named Jira group. It lives under Settings → Who can see this portfolio on the Portfolio page. That group (plus admins) then sees the portfolio and gates every project’s Tollgate tab. See Restrict access with governance groups.

A project’s Tollgate tab defaults to that project’s own governance people, plus Jira project admins. That means the project lead, the named seats (sponsor, PM, customer/supplier rep) and the steering committee. To grant one person edit access on a single project, the project lead nominates them as an editor. Open the project’s Tollgate tab, open Settings (the gear), and add them under Who can edit. Only the project lead sees the add and remove controls.

One nuance worth knowing up front:

Note

Per-project access and portfolio-wide access are two separate grants. An individual with access to one project sees that project’s row in any Portfolio view that includes it. They won’t see the other projects unless they’re also in the governance group set at the portfolio level.

For the precise rules — every role, permission and Jira scope — see Roles, permissions & scopes.

What’s next

You’ve got the map. Now build something real on it.

• Your first investment: thesis → gate — the flagship tutorial, end to end.
• Glossary — every term in one place if you’d rather look words up as you go.