Catalog Management: Permissions, Archiving & Cleanup

Explain how BI administrators manage catalog folder permissions, perform archive/migration operations, and keep a large web catalog clean and performant.

As a deployment matures, the web catalog inevitably accumulates thousands of analyses, dashboards, and one-off exploratory objects, and a large chunk of a BI administrator's ongoing job is exactly this: keeping that catalog organized, correctly permissioned, and free of dead weight. Interviewers ask about this because it's unglamorous, genuinely necessary operational work that separates someone who's only ever built content from someone who's actually run a platform.

It's like managing a shared company file server that's been in use for a decade: permissions set on a parent folder years ago quietly apply to every new subfolder unless someone actively checks, old abandoned project folders pile up and make search useless, and deleting a seemingly unused file without checking what still links to it can break something nobody remembered depended on it.

Key Concepts

Permissions management happens through Catalog Groups and Application Roles applied at the folder level, with permissions inherited downward unless explicitly overridden at a subfolder — a common admin task is auditing whether inherited permissions on a sensitive subfolder were accidentally left too permissive, since a broad grant at a parent folder silently cascades to every child object unless someone deliberately tightens it. The Catalog Manager tool (both GUI and command-line runcat.sh/runcat.cmd) is the primary tool for bulk permission changes, and for archiving/unarchiving — packaging a folder's contents (with or without permissions) into a portable .catalog file for migration between environments or for backup purposes.

Permissions managementCatalog GroupsCatalog Managerarchiving/unarchivingruncat.sh

Cleanup relies heavily on the Usage Tracking data discussed earlier: identifying analyses and dashboards with zero or near-zero executions over a meaningful window (say, six to twelve months) as strong candidates for archival or deletion, since an oversized catalog slows Presentation Services' own folder-browsing performance and creates confusion for users trying to find the "real" certified report among dozens of abandoned duplicates. Best practice is to archive before deleting (never destructively remove without a recoverable backup) and to establish a periodic (quarterly or semi-annual) cleanup cadence rather than letting it become a rare, panicked, all-at-once effort.

Cleanuparchive before deleting

A nuance worth raising in interviews: catalog object dependencies (an agent referencing an analysis, a dashboard prompt referencing a presentation variable used by several analyses) mean that deleting something "unused" without checking for indirect references can silently break other content — Catalog Manager's search/dependency-checking capabilities should be used before any bulk deletion, not just usage statistics alone.

object dependencies