Tag or categorize reports??

[mmavis]

How do you guys organize your reports so users can easily find what is relevant? We have so many reports, and more being asked for and created all the time, that putting them into dashboards is getting out of hand. The dashboards get super long. I thought it would be useful to use filters and groupings in the list, and the concept of report tags or categories would help. One report could have several tags/categories and the users could filter or group on them. For example, one report could have a category of sales (relevant for salespersons) and finance (relevant for those looking for financial information) and manager (relevant for managers). Then when a salesperson filters for reports tagged "sales", she'd see this report, and when an manager filters for reports tagged "manager" she would also see this report.

Does that make sense? Has anyone found a way to do this kind of thing? I wondered about using the description setting of the reports and standardize on words we could use as tags, but that lends itself to a lot of errors of misspelling and so on.

[NRYNR]

Hi Mavis, Welcome to the world of what I call “chaos exploration”. While creative tags in the descriptions of reports and dashboards can help you create creative reports of‚Ķ reports and dashboards, it only gets you to a place where end users see what you want them to see when you want them to see it. However, it doesn’t help you as the drowning system administrator. And it’s not just reports and dashboards you’re drowning in, but rather everything from custom forms, portfolios, projects and templates to custom views and EVERYTHING else you’re trying to manage in your system. Forget using the native tools to organize your creations‚Ķ it just doesn’t work when working with volume. About a year ago, I developed WFPro Package Manifest<>, a tool set that allows me to organize the artifacts of projects I create and my (work) life went from chaos to simplicity, literally overnight. Now, when my team at Truist creates anything for a client/stakeholder, we add the artifact to the manifest of a project. Put simply, we never have to wonder what we’ve created, when we created it, or how to find it because the manifest has all the answers. For example, I have a project that was developed years ago and, when the team came to me last week asking for us to create 10 new programs within their portfolio, along with 10 new security groups, it was simple for me to understand what we built for them by simply reviewing the manifest. I invite you to watch the “Keeping a Manifest<>” segment of WFPro Live 11, which was recorded during LEAP’s virtual event this year. The tools have evolved somewhat since then, and are really the only reason my team can maintain our sanity in a world of constant change and chaos. Nothing in my 8+ years as a full-time system administrator has been so beneficial to my work as WFPro Package Manifest. Let me know when you’re ready to see it in action and I’ll show you how the manifest keeps us rockin’ and rollin’ at Truist, including automated reporting to leadership that shows the objects we’re creating and who we’re creating them for. Sincerely, Narayana “The WFPro” Raum