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.

A mature deployment accumulates thousands of catalog objects. Keeping them organised, permissioned and pruned is a real part of the administrator's job.

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 are applied at folder level and inherited, granted to Application Roles rather than users.

    /shared/Sales              read: Sales Consumer
                               write: Sales Author
      /Dashboards
      /Analyses
      /_filters                shared filters and prompts

Granting at the folder and inheriting is what makes this maintainable. Per-object permissions are how a catalog becomes impossible to audit.

Catalog Manager does what the web interface cannot.

    search across all objects for a subject area or column reference
    rename a column reference in bulk
    report on permissions across the catalog
    archive and unarchive folders

The bulk rename is the one that saves a project. When the RPD renames a presentation column, every analysis referencing the old name breaks. Catalog Manager rewrites them in one pass.

Archiving moves content between environments.

    archive a folder -> a .catalog file -> unarchive in the target

The risk is overwriting. Unarchiving over an existing folder replaces what is there, including anything created directly in the target — which in production includes user content nobody knew about.

So promote specific folders rather than whole trees, and take a backup first.

Cleanup, and where the weight actually is.

    /users    personal folders, including those of people who left.
              These grow forever and nobody owns them.
    /shared   abandoned analyses, superseded dashboards, and
              "test" objects from three years ago

Usage tracking tells you what to remove. A catalog of four hundred analyses of which sixty ran this year is a defensible case for archiving the rest — and it is evidence rather than an opinion, which is what makes the conversation possible.

Archive rather than delete. Move candidates to an archive folder, wait a quarter, and delete what nobody asked for. Deleting outright produces the one request that proves the report mattered.

Why this is unglamorous and asked about. It distinguishes somebody who has built content from somebody who has run a platform. A slow catalog, permissions nobody can explain, and dashboards referencing columns that no longer exist are all the same neglect.

What the interviewer is probing.1. "How should catalog permissions be structured?" Probing: the governance. Stalls: "Per object." Moves up: on folders by application role, inherited by contents — object-level permissions become unmaintainable at scale.

2. "What is the archive and unarchive process for?" Probing: the mechanics. Stalls: "Backup." Moves up: moving content between environments or taking a restorable copy, preserving permissions and internal references.

3. "What does catalog growth cost you?" Probing: the practical angle. Stalls: "Disk." *Moves up:* slower search and startup, and a shared folder nobody can navigate — which pushes people to rebuild rather than reuse.

4. "How do you decide what to delete?" Probing: the method. Stalls: "Ask people." *Moves up:* usage tracking — anything unrun for a year, archived first so it can be restored if someone objects.