Jira dashboard for all customer onboarding projects

Build one Jira dashboard for all customer onboarding projects by giving each customer one epic with a Due date for its target go-live, adding each milestone as a dated child item, and saving filters that the dashboard reads. Set Health on each epic at every review using one at-risk rule the delivery leads agree on, because a saved filter can find overdue milestones but cannot judge whether a go-live date will move. Start with the project structure, since it decides which views your site can build.

Should all customer onboarding projects share one Jira project?

Put every customer onboarding epic in one shared Jira project when one filter and one dashboard should cover all customers. Use a separate project only for an account whose data must stay apart from the rest. Reliex's guide notes that native milestone options work inside one project.

Write down who needs the leadership view before you choose. A PMO that needs every account and a delivery lead who needs one account need different access, so let that list decide the structure. In a shared project, one filter covers every customer, so ask your Jira admin whether everyone with access can see every epic before any customer data goes in. In a project per customer, each customer stays separate, but the leadership view then depends on the cross-project check later in this guide.

Which fields should you create before building the dashboard?

Create a date field named Agreed go-live date and a single-select field named Health with the options Red, Amber, and Green before you build any filter. Reliex's guide says Jira has no milestone field or milestone work type out of the box, so milestones here are dated child items with a milestone label.

Ask your Jira admin to make these changes in the onboarding project, then check each one on the screens that epics and milestone items use.

1. Create the Agreed go-live date field. It holds the date agreed at kick-off, and the lead compares it with the epic's Due date at each review.
2. Create the Health field as a single-select list with the options Red, Amber, and Green. Leave it empty on new epics until the first review.
3. Add both fields to the epic create and edit screens. Confirm that the Due date field appears on the epic and milestone item screens.
4. Ask whether a milestone issue type already exists. If it does not, add the label milestone to each milestone item instead. The filters below use that label.

Keep the meaning of Due date fixed. On the epic, Due date is the target go-live date. Milestone items use Due date for their own deadline. The layout, the filters, and the FAQ below follow that split.

How do you set up one epic per customer with dates?

Create one epic for each customer, set its Due date to the target go-live date, and fill in the same fields on every epic. jira-templates uses the same shape: one epic per customer with account size, a customer success manager, stakeholders, and a target go-live date.

Fill in every epic with this layout:

Epic title: [customer name] onboarding
Due date (target go-live): [target go-live date]
Agreed go-live date: [date agreed at kick-off]
Kick-off date: [kick-off date]
Delivery owner: [name]
Customer sponsor: [sponsor name and role]
Account size: [size category your team uses]
Health: [Red, Amber, or Green]

The Agreed go-live date field keeps the baseline, so when the target moves, the lead can see both dates side by side. Do not overwrite the baseline to match the new target.

How do you add milestones that can be flagged late?

Add each milestone as a child item under the customer epic, with a name, a Due date, and a done state that means its evidence is attached. Reliex's guide says a milestone needs a name, a date, and a way to see whether the work behind it is done. jira-templates lists its milestones as checklist items, not dated items.

The jira-templates page lists kick-off complete, first workflow live, team trained, and go-live signed off as checklist items. Turn each one into a dated item:

1. Create the milestone items under the first customer epic, using the names your team agreed.
2. Set each item's Due date from the plan the sponsor has agreed to.
3. Add the label milestone to each item.
4. Mark an item done only when its evidence is attached. For go-live sign-off, the evidence is the written sign-off from [sponsor name].
5. Copy the items to each new customer epic, and change only the dates.

If your team already uses a Fix version for client handovers, that release can stand in for the go-live milestone. Reliex's guide calls releases the closest thing to a native milestone. For most onboarding milestones, a dated child item is the simpler choice.

Do not move a done milestone's date to hide a slip. Write the change in the item's description instead.

What counts as at risk, and how is Health set?

The lead sets Health at each review using one rule. Amber means a milestone is past its Due date and not done. Red means the epic's Due date is later than its Agreed go-live date, or the lead judges that a late milestone will move the go-live date. Green means neither applies.

Red takes precedence over Amber when both apply. The rule is the team's working rule, not a standard from any listed source, so agree it with the delivery leads and adjust it to your contracts.

Split the work between the filter and the lead. The milestone filter finds open items past their Due date, so nobody searches by hand. The epic filter does not compare an epic's Due date with its Agreed go-live date, so the lead checks that pair at each review.

A milestone waiting on a sponsor decision is still open, so it appears in the overdue results once its Due date passes. Ask for the decision in writing with a line like this:

We need a decision on [decision] by [date], or [go-live milestone] moves.

Velaris says effective dashboards highlight milestone delays so teams can fix friction before it drives churn. Update Due dates before each review, because the rule can only report the dates it is given.

How do you build the dashboard from the filters?

Save an epic filter and a milestone filter in your onboarding project, then add dashboard gadgets that read each one. Titanapps lists saved filters with JQL as a way to get a customized view of issues, and ONES describes a cross-project layout built on one saved filter that you can adapt.

1. Save the epic filter, replacing the project key with yours:

project = [onboarding project key] AND issuetype = Epic AND statusCategory != Done ORDER BY duedate ASC

2. Save the milestone filter the same way:

project = [onboarding project key] AND labels = milestone AND duedate < now() AND statusCategory != Done ORDER BY duedate ASC

3. Add the dashboard gadgets.
   • a chart that counts open epics grouped by Health;
   • a gadget that lists results from the milestone filter;
   • a gadget that lists results from the epic filter, sorted by Due date.

Do not type milestone dates into a text gadget. ONES lists stale shared dashboards among common dashboard challenges, so let the filter results carry the dates.

4. Name the dashboard for its reader, for example [onboarding status for leadership].
5. Count the open epics by hand against the epic filter's results before anyone relies on the dashboard.

Keep a separate dashboard for the delivery team. Write the date of the last Health review in its description, so readers can see how old the values are.

How do you keep one customer's data out of another's view?

Before you share the dashboard, ask your Jira admin whether everyone with project access can see every epic, and whether individual issues can be restricted. If one account's data must stay private and cannot be restricted, give that account its own project before anyone sees the dashboard.

1. Write down who needs every customer, and who needs only one account.
2. Ask your Jira admin the two questions above, and write down the replies.
3. If an account needs its own project, move its epics there. A leadership view across projects then depends on the Plans check below.
4. Keep contract terms and named contacts out of filter names, dashboard names, and epic summaries.
5. Test the setup. If your team has a test account limited to one customer, sign in with it and check that no other customer's epics appear. If they do and access cannot be narrowed, move that account before you share the dashboard.

Record the check in the dashboard's description:

Dashboard: [dashboard name]
Shared with: [group or people]
Customers in view: [all customers or named accounts]
Access checked by: [name] on [date]

Keep this note with the dashboard, so the next review repeats the check.

Can you see milestones across projects without Jira Plans?

Reliex's guide says a cross-project view of milestones needs Jira Plans or a Marketplace app, and lists Jira Plans for Premium and Enterprise. Ask your Jira admin to confirm which plan your site has. Without either, the native build in this guide covers one project at a time, so keep all customer epics in one shared project.

If your admin confirms that your site has Jira Plans, keep each customer project as it is, and use Plans to bring the onboarding epics into one view. Ask your admin to confirm that the Due date and Health fields show in that view before you rely on it.

If your admin says cross-project planning comes from Advanced Roadmaps, ask them to check whether it is the same feature as Jira Plans before you rely on it. Do not assume the two match.

If your site has neither, keep every customer epic in one shared project. The saved filters and the dashboard then cover all of them, and the leadership view needs no cross-project feature.

If your admin wants a Marketplace app, have them check its plan requirements and data access before anyone installs it. This guide does not recommend one.

When does one late milestone put a whole account at risk?

One late milestone sets its customer epic to Amber, not Red, unless the lead decides that it will move the agreed go-live date. Name each milestone item with its workstream so the overdue results show which part of the project is late. The steps below follow one case from start to finish.

Use the milestone name form [workstream name]: [milestone name]. The following example is illustrative, with placeholders in place of every name, date, and decision:

1. [Customer name] has a milestone item named [workstream name]: [milestone name], with a Due date of [due date] and no evidence attached.
2. At the [review date] review, the milestone filter lists the item, because its Due date has passed and it is not done.
3. The lead sets the epic's Health to Amber.
4. The lead asks the question: does this late item move the agreed go-live date of [agreed go-live date]? If not, the epic stays Amber and the reason goes in the epic's description. If yes, the lead sets Health to Red.

Do not set Red only because a milestone is late. Ask the question first.

Velaris describes an account-level rollup across multiple onboarding journeys. Apply the same idea here: one workstream's late item is a reason for review, not an automatic account-wide status.

Where does Jira stop working for this?

Jira works for this when your team already runs onboarding work in Jira and your plan supports the cross-project view you need. It stops working when a leadership view must cross projects without that feature, when a customer needs its own status view, or when the real gap is a decision the sponsor has not yet made.

Check the plan question with your admin before you commit to a cross-project view. Customers who need a status view should get a short written note from the lead, built from the Health value and the next date.

A dashboard can show a Red row without anyone asking the sponsor for a decision. Before each review, the lead settles who acts on each Red row and what they ask the sponsor for. Velaris says the best onboarding dashboards do not just report data; they trigger workflows, alerts, and interventions that turn insight into action.

Common questions about keeping the dashboard current

Keep the dashboard current by setting Health before each sponsor meeting and whenever a milestone's status changes, then writing the date of the last review in the dashboard description. Change a Due date only after the sponsor agrees to the new date, and record the reason in that item's description.

What should the lead do next?

Pick a few active customer projects, create the fields and epics in the layout above, and agree the Health rule with the delivery leads before you save any filter. Review the first dashboard before the next sponsor meeting, and change only the rules that caused confusion.

1. Ask your Jira admin to create the Agreed go-live date and Health fields, and add them to the epic screens.
2. Create the epics for your active customer projects using the layout above.
3. Add the milestone items, label each one milestone, and set their Due dates.
4. Save the epic and milestone filters, build the dashboard, and check its counts against the epics by hand.
5. Review each Red and Amber row with the delivery lead. For each one, send the sponsor this line, filled in: We need a decision on [decision] by [date]. If it slips, [consequence].
6. After the first sponsor meeting, keep the rules that worked and drop the rest.