[Feature Request]: Visually Distinguish Global vs Tenant‑Scoped Menu Items

[Lowell-Syncrety]

Please confirm:

• I have searched existing feature requests (open and closed) and found no duplicates.
• **me or my organization is currently an active sponsor of the product at the $99,- level.

Problem Statement

CIPP currently mixes global and tenant‑scoped functionality within the same navigation sections, which is logical from a workflow perspective but not visually obvious to the operator.

For example, under Identity Management → Administration, tenant‑specific items like Users and Groups appear alongside Group Templates, which are global in scope. While the placement makes sense functionally, there is no visual indication that actions taken in Group Templates affect all tenants rather than the currently selected tenant.

This creates confusion, particularly for:

• New technicians
• Junior staff
• Anyone working quickly under the assumption that the selected tenant context applies to all nearby actions

The risk is not theoretical: modifying a global object while believing you are operating tenant‑locally can result in unintended cross‑tenant impact. As an admin myself I'm still running into this and have to double-check other clues in the resulting UX page to make sure I'm doing something global or tenant-specific.

Benefits for MSPs

• Reduced operational risk: Clear scope indicators help prevent accidental global changes when a technician believes they are working within a single tenant.
• Faster onboarding and training: New technicians can immediately understand what scope they are operating in without needing tribal knowledge or warnings.
• Improved confidence and speed: Technicians can move faster without second-guessing whether an action is global or tenant‑specific.
• Clearer mental model of CIPP: Explicit scope signalling reinforces how CIPP separates global configuration from tenant execution.

Value or Importance

This is a UX safety and usability improvement rather than just a cosmetic change.

CIPP is increasingly powerful, and with that power comes the need for clear scope boundaries. Making scope explicit in the UI helps prevent high‑impact mistakes, aligns with MSP operational realities, and improves the experience for both new and experienced users.

Given CIPP’s role as a centralized, multi‑tenant control plane, scope clarity is critical.

Proposed UI Approaches

Any one of the following would significantly improve clarity without changing existing workflows:

Visual Styling

• Global items displayed with a subtle but distinct style (e.g., different text color, bolding, or background accent)
• Tenant‑scoped items retain current styling-

Icon or Badge

• Small, consistent icon (e.g., 🌐 or similar) next to global menu items
• Optional tooltip: “This action applies globally across tenants.”

Scope Labeling

• Inline label such as (Global) or (Tenant) next to menu entries
• Especially helpful in mixed sections like Identity Management

Contextual Warning (optional enhancement) in the UX page along with a menu enhancement above)

• Lightweight notice/banner when entering a global section while a tenant is selected: “You are editing a global configuration, not the selected tenant.”

These options are intentionally lightweight and do not require restructuring the navigation or relocating features.

PowerShell Commands (Optional)

No response

[Lowell-Syncrety]

Forgot to note... There are menu items that default to applying to the selected tenant, but also provide the capability of applying multi-tenant. I don't think these would need to be separately identified, but if using an icon (e.g., the globe icon for global sections) some sort of "multi-tenant" icon could be used.

[github-actions]

This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.

[Lowell-Syncrety]

So to be clear, when we take the time to draft up and post a feature request, that just disappears after a short time if there's no "activity" on it? Why can't a feature request be open until it's actually responded to by the dev team (i.e., not going to develop and why, already developed, on the roadmap, etc.)?

[KelvinTegelaar]

Answered in discord too, but pasting here for completeness sake:

A month in CIPP times isn't short, that's two releases. ;).

Many larger vendors such as Microsoft work through the same method now on all of their repositories, Red hat, N8N, or more specifically MSP software; Netbird & N-Able all have restructured to take the same approach. Short lived feature requests that get picked up, or can be resubmitted at a later date to see if they make more sense at that point.

Having shorter development cycles, and thus shorter times that feature requests are open prevents stale issues and things having to be sorted by development teams, and allows faster iterations. Sometimes a feature is developed in unison that replaces a feature request, and sometimes a feature just isn't picked up by a developer due to a lack of time or prioritization. We're way above the avg. of released feature requests,(around 18~ per month, compared to the 0.6 per month for the MSP industry)

Closing a feature request over short times also prevents the entire issue with people not knowing where they are at. In our industry we see that a lot with boards like Canny or IT-Glues board. The most upvoted feature has been open for 6 or 7 years, and there is no movement on it. Having a short-lived feature board manages expectations a lot better - You can see what's coming, what items have been road mapped or prioritized, and if an item has gone stale you know that the development team hasn't picked that item yet, however there is no barrier to resubmit the request later or as we're entirely open source to contribute yourself.

Hope that explanation helps a little.