The integration dashboard nobody tells you about

Most implementers don't scope this in. Somewhere in the delivered content library sits a full Integration Performance Dashboard, ready to migrate into your tenant, and it rarely makes it onto anyone's implementation plan. Once the tenant's live and the project team has moved on, nobody circles back to it either.

So most teams end up running one of two ways instead. Either someone checks the Integration Events report when they're chasing a specific run, which works fine for the thing you already know about, or the team leans entirely on notifications and finds out something's wrong when the notification tells them.

Notifications feel like the safer bet at first. They're not. They tend to be fairly black and white, an integration either succeeded or it didn't, with little room to filter out the failure modes you don't actually care about versus the ones that need eyes on them right now. And I'll say this from firsthand experience: notification fatigue happens fast, and it usually sets in about a month or two into a go-live. You start skimming past alerts instead of reading them, which defeats the entire point of having them.

What the dashboard actually gives you

The delivered Integration Performance Dashboard package (RPT Integration Performance Dashboard, if you're looking for it in Configuration Catalog) bundles together nine reports:

• INT Performance for Jobs, Reports, and Web Services, each showing average and total processing time by process type

• INT Performance Schedule Balancing, showing total processing time by time slot across a day

• INT Performance Top 10 Worst Integration Events and Top 10 Worst Integration Systems, ranked by total or average processing time

• INT Last 7 Days Activity

• INT Most Recent Event Failures

• INT Today's Status, showing where every background process stands right now

That's a genuinely useful spread for spotting drift before it becomes a problem, rather than finding out from an angry email or a fatigued glance at a notification.

Worth saying plainly though: not all nine earn a permanent spot on your worklet. A few of these will become the ones you actually open every week. Others will sit there generating noise until you either archive them or stop looking. Go in expecting to prune, not to keep the whole set exactly as delivered.

How to actually get it into your tenant

This isn't a click-and-go install, but it's not a heavy lift either. Here's the walkthrough, based on Workday's own documentation for this package.

Before you start:

• You'll be using Object Transporter (OX) (see here and here) and the Configuration Catalog in Customer Central (see here), so get familiar with both if you haven't used them before.

• Make sure your Customer Central User ID matches the user ID in the Sandbox or implementation tenant you're migrating into.

Set up the security first:

• Confirm the Integration Administrator security group exists (Reference ID: Integration_Administrator).

• Check the Integration Reports domain is enabled and configured with that security group. This is what secures the dashboard itself.

• Give the Integration Administrator group View access to the Integration Build, Integration Debug, and Integration Event domains, wherever they're applicable in your tenant.

Migrate the package:

• Head into the Configuration Catalog and migrate the RPT Integration Performance Dashboard package.

• Test it thoroughly in Sandbox first. Workday's own guidance is explicit that testing and confirming everything meets your regulatory and business requirements is on you, not on Workday support, since this content sits outside standard customer support.

• Once it checks out, use Object Transporter to migrate the dashboard and its supporting components to Production, following the same steps you used for Sandbox.

Expect to tidy up afterward: A few post-migration tweaks are common and expected: updating calculated fields (search cf: plus the field name and edit from there), adjusting filters and default prompts on the reports, updating sharing on both the reports and the dashboard itself (System Auditor access on both is a sensible default), and cleaning up the dashboard worklets and menus to match how your team actually wants to use it.

Worth the afternoon

This is a genuinely good way to get real hands-on time with dashboard configuration as an integration admin, and with Workday's reporting functionality more broadly, well beyond what this one package covers. It's the kind of thing you can work through in an afternoon when things are quiet. Pick a Friday, assuming nothing's on fire. If something is on fire, let's put that out first, and get to this another day.