A Forge app REST API is called from outside Jira with an OAuth 2.0 (3LO) access token. This walks the whole path with curl against LeanZero Management: the admin switch, the integration and its scopes, consent with sns, the token exchange, rotating refresh tokens, and the four 403s I hit on the way.
A 5,300-issue plan put 94,920 nodes in the DOM. Windowing the rows took it to 2,115 — and left a second full-height layer that windowing does not touch.
A Forge PPM app needs a live in-browser scheduler and a server-side one. They drift by a day, no test goes red, and the user believes the preview. Here is the harness that catches it — and the two mutations I ran to prove it works.
A blocks link in Jira records a relationship. On Free and Standard it reschedules nothing. Here's the engine we put behind it, the required-start rule that's easy to get subtly wrong, and what it still can't do.
Drag one date, the whole chain re-plans, and Apply writes it back to Jira.
A task with three predecessors starts the working day after the last of them finishes, plus any lag on the link. Merge points are where most roadmap tools quietly get the date wrong.
Weekends and plan holidays come out of the arithmetic. A due date on a non-working day stays put, and the work it blocks starts the next working day.
A buffer task holds its due date while its duration shrinks, so upstream overruns are consumed before your delivery dates move.
An epic always spans the work under it, on the Timeline and in what Apply writes. A Done ticket is never moved by a schedule change.
17 tutorials
Open a Jira plan and get five answers at once: will we hit the date, what is blocked, what changed, what to do next, and can you trust it.
Read a Jira Gantt chart of 1,978 open work items in one screen: the epics that hold work, the chain that sets the finish, and what needs you.
Drag one date on a Jira Gantt chart and every dependent issue moves with it; review the eight changed issues, then Apply them to Jira.
Bulk edit Jira due dates in a scheduler's table: pick five new finish dates, review them, then watch Apply write each one and read it back.
Add a lag to a Jira dependency: draw the link on the Gantt, set two working days, and Apply writes the link first and the dates after it.
Keep Jira plan numbers honest: one dated share on every page, and a what-if counted only on your screen until you decide to save it.
Read a Jira project dashboard that answers the sponsor's questions: when it lands, how sure that date is out of 100, and what risks drag it.
Write a Jira sponsor report without retyping a number: the draft opens on the plan's frozen figures, and you add the headline, notes and decisions.
Publish a Jira status report to Confluence for an external sponsor: ticket keys and names hidden, and every send sealed as a version.
Review every Jira date change before it is written, let the app and an AI check the plan, then Apply or Discard All with nothing written.
Get a Jira plan brief in seconds: the one thing to know, the decisions to ask your sponsor, the next moves, and a Monday update to paste.
See a Jira plan as a few storylines: the AI groups 257 linked issues into named chains of work and puts the one that sets the finish first.
See every Jira plan's status on one page: which are late, which need you today, and a portfolio summary you can paste into an email.
Set a Jira project baseline in one click, then see exactly which issues slipped against it, compare forecasts, and try changes in private.
Set up a Jira plan from plain words: let AI write the JQL that Jira checks, choose a calendar, and the plan opens with its status.
Set up LeanZero Management in Jira as an admin: see what the AI sends and spends, cap it per day and month, control plan access, connect REST.
Add the LeanZero Management issue panel to a Jira ticket and see where it sits in the plan: what it waits on, and what waits on it.
5 answers on every tab
The plan's status against its commitment, with the room left in working days and the chance of making it from the forecast.
Past-due and blocked work, each naming what waits on it. One click shows them on the Timeline.
Whether the finish moved since you last looked, which items slipped, and what was edited in Jira.
Up to three next moves taken from the plan itself, with no AI: scope a target, unblock an item, fix a dependency loop.
How much of the open work has usable dates. When less than 80% is dated, the plan reads Late (at least) or Can't tell yet instead of On track.
What stops the forecast, what says something untrue and what limits what can be judged, each with a count and the fixes that apply. Nothing on it writes to Jira.
Draw a dependency between two bars and give it a lag. The lag belongs to the Jira link, and the Apply review shows it, for example Lag 2 working days.
Dates a colleague saved that rely on a dependency they have not applied yet are held back from your Apply, and the review says which link and who staged it.
If a colleague draws the same link with a different lag, Apply asks which lag the link keeps and writes nothing until you choose.
A write lock per plan, a conflict check for anything changed in Jira meanwhile, and an Apply that stops partway resumes without sending any issue twice.
Write a headline, a note under any line, and decision requests with options, a date and an owner. The verdict, the commitments and the finish cannot be edited.
An external report hides ticket keys, Jira links, names and quoted comments by default and says so. A check before Send flags a headline that contradicts the plan.
Every send, as a download, a Confluence page or plain text, seals a numbered version that never changes. The next report carries your edits over where their lines are unchanged.
6 features, each with its own switch
Opens from the Apply review. The app's own checks come first; the AI then reads up to 120 issues, your staged changes first. Findings your plan's dates disprove are dropped.
The one thing to know, the decisions for your sponsor and the next moves, computed by the app. The AI drafts the update, and every sentence it keeps is traced to a computed fact.
The AI groups the plan's linked work into a few named chains and puts the one that sets the finish first, with the room each one has left.
Reads the newest comments on the tickets that matter and quotes them word for word. Restricted comments, internal service desk comments and who wrote a comment are never sent.
You open a plan only when Jira lets you see every project and issue it is built from. Apply writes each change only where your own Jira account could make it.
One switch for all AI features and one per feature, daily and monthly caps, and today's and this month's usage per feature with what each one sends.
Atlassian's app REST APIs with three permissions: read, change and administer plans. A call acts as the person who signed in, so their plan and Jira permissions still apply.
Sixty days of who applied changes to Jira and who changed plans, reports, access, settings and AI features, read or downloaded by a Jira administrator over the REST API.
101 sections
A Forge app for Jira Cloud that reads a chosen set of Jira issues into a plan, forecasts when the work lands against the dates you promised, and writes date and dependency changes back to Jira only when you apply them.
Jira stores a start date and a due date on each issue, but it has no schedule that reacts. Move one issue and nothing that waits on it moves, parents do not follow their children, and nothing tells you whether the work still lands before the date you promised. LeanZero Management adds that layer on top of your Jira issues.
You build a plan by saying where its issues come from (JQL queries, boards or whole projects). The app reads those issues, and the issues under them, into its own copy of the plan. Every plan then opens on the same tabs: Timeline, Table, Dashboard, Storyline, Capacity and Reports. The top of every plan answers five questions: will we hit the target date, what is late or blocked, what changed, what to do next, and can I trust these numbers.
A full page with Plans, Portfolios and Capacity in its top bar, a panel on every Jira issue, and a settings page for Jira administrators.
| Where | Title in Jira | What you get |
|---|---|---|
| Apps menu (full page) | LeanZero Management | The app itself. Its top bar has three pages, Plans, Portfolios and Capacity, plus What's new and the version your site is running (the same number Manage apps shows). On a phone the three pages sit in one menu. |
| Jira issue view | LeanZero Management Position | Where this issue sits in a plan: how much room it has before it moves the plan's finish, what it waits on and what waits on it, with a CRITICAL PATH chip when it has no room. A PM and an Engineer view phrase it for each reader. When the issue is in several plans, a row of plan names lets you switch. When it is in none, the panel says "This issue is not in any LeanZero plan." |
| Jira settings, Apps | LeanZero Management Settings | Site-wide settings in six tabs: Calculation Engine, Field Mapping, Display, Plan Permissions, Maintenance and API Access. Maintenance holds the AI features card with the master switch, a switch per feature and the daily and monthly limits. |
Every hour the app refreshes each plan from Jira. When an issue in a plan changes in Jira, the app updates that issue in every plan that holds it. A dependency added or removed in Jira reaches the plan within seconds. None of this needs anyone to have the app open.
New plan on the Plans page opens a five-step wizard: Name, Sources, Schedule, Targets and Review.
On the Plans page, press New plan (on a phone, New). The wizard, headed Create a plan, has five steps across the top. You can click back to any step you have finished but not forward past one you have not. The footer's back button carries the previous step's name (for example ← Sources), Cancel leaves the wizard, and Continue → moves on.
| Step | What you do | Blocks Continue? |
|---|---|---|
| 1 Name | Type the plan's name (up to 120 characters), or click one of the suggestions. Enter moves on. | Yes, until the name has text |
| 2 Sources | Add one or more JQL, Board or Project sources. | Yes, until every source is filled in and no JQL query has been rejected by Jira |
| 3 Schedule | Pick a working calendar and who can see the plan (Visibility). | No |
| 4 Targets | Optionally add dates the plan promises, each a name and a date. | No |
| 5 Review | Check the summary and press Create & Index. | Not applicable |
The step starts with one JQL source called Source 1. Each source has a name you can edit, a JQL / Board / Project switch and, when there is more than one source, a × to remove it. + Add another source adds another. A JQL query is checked by Jira as you type and shows Valid with an approximate count, an error in red, or a warning when it is valid but finds nothing you can see. A query still being checked does not block Continue; only one Jira has rejected does. The next section describes the three source types.
Working calendar lists the site's calendars (by default Standard (Mon–Fri) and Israel (Sun–Thu)), each with its working days spelled out. Visibility sets who can open the plan before you add anyone by name: Private (Only you and members you invite), Everyone can view, Everyone can edit or Everyone can administer. Private is selected by default. You add named members later under Plan settings, Permissions.
Optional. Each row is a name (up to 80 characters, for example Go-live) and a date. Rows missing a name or a date are dropped when the plan is created, and a plan holds at most 24 targets. The latest target becomes the plan's commitment, the date the plan's status is judged against. You can add, change or scope targets later under Plan settings, Targets.
Import a Jira plan turns a Jira Premium plan into a LeanZero plan with the same sources and date fields, without changing the Jira plan.
On the Plans page, open More and choose Import a Jira plan (the empty Plans page also shows this button). The import has four steps: Jira plan, Preview, Settings and Import. It reads plans from Jira Premium Plans (formerly Advanced Roadmaps) and copies the plan's issue sources, its exclusion rules and the date fields it schedules on. The Jira plan itself is never modified.
What each source type pulls in, how it is checked, how several sources combine, and how to change them after the plan exists.
| Type | You give | What the plan reads |
|---|---|---|
| JQL | A query | Every issue the query matches. |
| Board | A board, picked by name | The board's issues. |
| Project | A project, picked by name or key | Every issue in the project, in rank order. For a subset, use a JQL source instead. |
In the wizard, Board and Project sources use a search box. Type to search, use the arrow keys and Enter to choose, Escape to close. A moment after you pick, a panel confirms what you chose. For a board: its name, its project, how many issues are on the board, and the JQL of the filter behind it. The plan also brings in the child issues and sub-tasks under them, so it can hold more rows than that count. For a project: its name, key, whether it is company-managed or team-managed, its lead, an approximate count and up to six of its issue types. If Jira cannot show it, the panel says Board not found (or no access) or Project not found (or no access).
Sources are read one after another and merged by issue key, so an issue that two sources match appears once.
The index pulls in every issue under what your sources match, can pull in missing parents, and marks issues whose parent is outside the plan.
A source rarely returns a whole tree. A query for epics returns only the epics, not their stories or sub-tasks. So after reading the sources, the index walks down Jira's parent field level by level and adds every issue under the matched ones, whatever your hierarchy levels are called. The hourly refresh does the same. This is why a plan is usually larger than its sources' counts: a query that previewed about 40 epics can index several hundred work items.
A source that matches a story but not its epic would leave the story at the top level of the plan. With Include parents on, the index also walks up and adds the missing parents, then their parents, and so on. It walks up only after walking down, and never walks down again from a parent it added, so adding an epic does not drag in all of that epic's other stories. Include parents is on for every plan created with the wizard or the import. It has no control in the app; it can be changed over the REST API.
When an issue's parent is in Jira but not in the plan, the Timeline shows the issue at the top level with a small badge reading ↑ and the parent's key. Clicking the badge opens the parent in Jira. Its tooltip says the parent is not in this plan, so the item shows at the top level.
Counts are of work items. An epic or parent that holds stories in the plan is not counted as work: it spans its children, and its dates come from them. An epic with no stories yet counts as one work item. If it has no dates, it counts as undated work, and the Timeline lists it under No dates with the other work that has no dates, instead of hiding it. Breaking one such epic into stories later changes that epic's count, not the size of the rest of the plan.
The date and scheduling fields the app relies on, the two it creates on first use, and where to change which field ids it uses.
| Field | Default | Used for |
|---|---|---|
| Start Date | customfield_10015 (Jira's Start date) | Each work item's start |
| Due Date | duedate | Each work item's finish |
| Duration | customfield_11581, or the PPM Duration field the app creates | Length in working days |
| Buffer | customfield_12399, or the PPM Buffer field the app creates | Marks an item as buffer (Yes or No) |
| Rank | customfield_10019 | Jira's rank order, which the Table's Jira rank sort follows |
The app also reads each issue's summary, type, status, parent, assignee, priority, labels, resolution, reporter, created and updated dates, sub-tasks, issue links and story points. Story points are always read from customfield_10016 and cannot be remapped.
The first time any plan is indexed, the app looks for fields called Start date, Duration (or PPM Duration) and Buffer (or PPM Buffer). If Duration or Buffer does not exist, it creates a number field called PPM Duration and a select field called PPM Buffer, and adds the three fields to the edit screens of the projects named in the plan's sources, and to the Default Screen.
A Jira administrator can point the app at other field ids in LeanZero Management Settings, Field Mapping. A plan imported from a Jira plan can carry its own mapping, so it schedules on that plan's date fields. Inside a plan, Configure fields in the ⋯ menu shows whether Jira will take the plan's changes on each issue, and can add missing fields to a project's screens after you confirm.
A Jira issue link becomes a dependency in the plan only when its type is the configured dependency link type (Blocks by default) and the issue at the other end is in the same plan. The same Jira link can therefore be a dependency in one plan and absent from another.
Nothing is invented at index time. An issue with no start and no due date has no bar of its own and counts as undated. Items without both a start and a due date are called not fully dated, and items whose start is after their due are named as dates that don't fit.
A plan's own roles decide what you may do in it, and Jira's project permissions decide whether you may open it at all.
Each plan has an owner (its creator), named members with a role, and a default access for everyone else, set by Visibility in the wizard. Jira administrators are plan admins on every plan. Viewers can read the plan. Editors can change its schedule, save and apply. The owner and plan admins can also delete the plan and manage who has access to it.
Since 4.12.0 you can open a plan only when Jira lets you see every project and every issue it is built from, including issues with a security level. This holds in the app and over the REST API. A plan you cannot see in full stays on the Plans page as a closed row, with what to ask a Jira admin for, and nothing else of it is shown.
| The row says | What it means and what to do |
|---|---|
| Closed by Jira permissions | Jira does not let you see some of the plan's projects or issues. Ask a Jira admin for Browse projects on every project in the plan, and access to any of its issues that have a security level. |
| Access not confirmed | Jira did not answer in time. Try again in a moment. |
| Needs a re-index | Something the plan is built from changed in Jira (a project deleted, archived, renamed or hidden from the app). The owner, a plan admin or an editor can re-index it. |
| Checked when you open it | Your access is checked when you open the plan. It opens if Jira lets you see everything it is built from. |
A plan holds only the issues that the person who created it, or who last saved its sources, can see in Jira. If that person loses access to some of them, the plan leaves them out at its next refresh. If they can see none of them any more, the plan empties and says so, naming who can fix it. If Jira no longer recognises that person, the plan keeps its data and stops refreshing. In each case an editor who can see all of the plan's issues takes it over by saving its sources.
Indexing reads every source, walks the hierarchy, keeps only what the plan's person may see, and stores the result. It runs in the background and never empties a plan by accident.
An index is queued and runs in the background with up to 15 minutes to finish, so a large plan does not time out. You do not have to wait for it: open the plan and it fills in when the index finishes. If a queued index never starts, or runs past its time, the plan reports that indexing did not start, or timed out, and asks you to retry. Press Refresh from Jira now to run it again.
If a re-index matches no issues but the plan held issues before, the app keeps the previous data, and the plan says that the last re-index matched 0 issues, that the previous data was kept, and to check the plan's sources. A permission blip or a query that stopped matching cannot wipe a schedule. The exception is a plan whose person can no longer see the issues it held: that plan is emptied, as described in the access section.
A refresh from Jira, manual or hourly, pulls fresh Jira data and puts your unsaved edits back on top from your autosaved draft. Edits you saved but have not applied are kept too, field by field, except on a field Jira itself changed since: there Jira's value wins, yours is dropped, and the app names the drop. When the plan holds edits like that, Refresh from Jira now asks you to confirm first.
It depends on how many issues the sources match, how deep the hierarchy under them goes, and how quickly Jira answers. A plan of a few hundred issues takes a handful of Jira requests. A plan of several thousand issues across several levels takes many more.
How the Plans page lists, words and sorts your plans, the busy states a plan passes through, and how plans stay current with Jira.
The Plans page is a table with one row per plan: Plan, Status, Commitment, Forecast finish, Next target and Needs attention, plus Trend · 7 days once plans have about a week of history. The Plan cell gives the name, the project keys, the size (for example 1,978 open work items), the owner and, when there are any, the undated epics with no stories yet. On a narrower window the table drops Next target first, then Trend, and leaves out whole details rather than cutting words. On a phone each plan becomes a short card with the same fields. Every date shows its year.
| Word | Meaning |
|---|---|
| On track | The forecast finish is before the commitment with more than 10 working days of room, and work has begun. |
| Tight | The forecast finish is before the commitment but with 10 working days of room or less, or half the work has no slack. |
| Late (forecast) | The forecast finish is after a commitment that is still ahead. |
| Overdue | The commitment date has passed and work is still open. |
| Late (at least) | Less than 80% of the open work has dates, and the dated work alone already finishes after a commitment that is still ahead. The gap shown is the least it can be: the undated work can only add to it. |
| Can't tell yet | Less than 80% of the open work has dates, and the dated work alone would read On track, Tight or Not started. The plan cannot vouch for that, so it does not say it. |
| Not started | The forecast finish is before the commitment with room, and the work has not begun yet. |
| No commitment | The plan has no target to be judged against. Inside a plan the same word reads No target. |
| Delivered | All the work is done. |
| Not measured | The app could not measure the plan's finish against its commitment. |
| Updating… | Right after an app update, the plan is being measured again under the new version's rules. It takes its place within seconds. |
Under the status word a line gives the confidence and its reason, for example Medium confidence · 64% dated or Low confidence · 17% dated. When less than half of a plan's open work has dates, the confidence is Low and the status chip is drawn outlined instead of solid.
Above the table a line counts every plan once: late, at risk, on track, can't judge yet, no commitment, not measured, delivered, behind a Jira check, and updating. Each count is a button that filters the table to those plans. Late includes every Late (at least) and Overdue plan whatever its confidence, and the line then says how many of them rest on low confidence, for example 12 late · 12 of them low confidence. Can't judge yet holds every Can't tell yet plan and every On track, Tight, Not started or Late (forecast) plan on Low confidence. The same line ends with Refreshed hourly from Jira and the time the list was read.
The table opens sorted Needs you first, in two groups: the plans judged from dated work, then those with too little dated work to judge. Within each group the plans that need a person come first, such as a plan with a blocked item, a commitment within a week or already past, or tickets past due, and in the first group a Late or Tight status. Plans being updated come next, and plans Jira closes to you come last. The other sorts are Nearest commitment, Biggest slip, Recently changed and Name, and you can group by Portfolio or Project.
| Shown as | What is happening |
|---|---|
| New | The plan was created but has not been indexed yet. |
| Queued… | A re-index is waiting its turn. What you see is from before it. |
| Indexing… | The plan's issues are being read from Jira. |
| Calculating… | The schedule is being worked out. |
| Being written to Jira… | Someone is applying the plan's changes. When the app knows who, it names them, for example Being written by Ana…. |
| Error | The last re-index failed. The plan says why; re-index it to try again. |
Every hour the app refreshes each plan from Jira. It skips a plan that was indexed in the last 55 minutes or is busy, first asks Jira cheaply whether anything in the plan's scope changed, and stores nothing when nothing did. Between refreshes, an issue edited in Jira is updated in every plan that holds it, and a dependency added or removed in Jira arrives within seconds. After a Save, a Discard All or an Apply, the plan is measured again so its row on the Plans page shows the new numbers. Refresh from Jira now in the plan's ⋯ menu runs a full index at any time.
A React custom UI talking to Forge resolvers, with plan data sharded across Atlassian's key-value store so a plan of several thousand issues stays inside the platform's limits. Indexing runs on a queue, dependency changes made in Jira arrive within seconds, and an hourly refresh keeps everything else in step.
The scheduling engine exists twice: once in the browser, where it has to be instant, and once on the server. A parity test suite settles the same plans through both and fails the build if they disagree, so what you preview is what gets applied.
Free. Install it from the Atlassian Marketplace and point it at a project you already run: it schedules the issues that are there, on the start and due dates they already carry, and adds its own PPM Duration and PPM Buffer fields only if your site has no such fields.
Something not working as described? Raise it on our support portal, open 24/7.