Manage an app

When you open Manage on a product from the Apps catalog, you land in that product's governance area. This is where admins and owners decide what people can see and do inside the app - its data policies, its roles and permissions, and its data settings.

A breadcrumb at the top - Apps › App name › Manage - keeps you oriented and lets you jump back to the catalog.

Only admins and owners can reach this area; that's why the Manage button is hidden from everyone else in the catalog.

Getting around

The Manage area is organized into three tabs, shown as an underline tab bar that doubles as the page heading. A short description below the bar changes to match whichever tab you're on:

• Data Policies - which records users and groups can see in this app.
• Access Controls - the roles and permissions for this app.
• Settings - data policy defaults and other options.

When you first open Manage, it lands on Data Policies.

Data Policies

The Data Policies tab controls which records a person can see inside the app, as opposed to which actions they can take. A data policy is a set of attribute-based rules; you assign it to users or groups, and a member of a group sees the union of every policy that applies to them.

From this tab you can browse the policies that apply to the app, search them by name or description, and open one to view or edit its ruleset and assignments. Creating and editing policies opens the full policy editor.

Data policies are an organization-wide capability that the app's Manage area surfaces in context. For the complete walkthrough - building rulesets, assigning policies, and how the default access mode works - see Data policies.

Access Controls

The Access Controls tab is where you define roles for the app and choose exactly what each role can do. It's a two-pane editor: a list of roles on the left, and the permission editor for the selected role on the right.

The role list

The left rail lists the app's roles, grouped into two sections:

• System roles ship with the app. You can edit their permissions, but you can't rename or delete them.
• Custom roles are ones you create. They can be renamed, re-permissioned, and deleted.

Each row shows the role's name and a quiet summary of how much of the app it can touch - for example "3 modules · 12 permissions". A search box filters the list by name or description, and selecting a role opens it in the editor on the right.

Creating a role

Choose New role to open the create dialog. Give the role a name (required) and an optional description. You can also turn on Clone permissions from and pick an existing role to copy its grants as a starting point, rather than building from scratch. The new role is created as a Custom role and opens in the editor.

Editing permissions

The editor shows the role's name and a System or Custom badge. For custom roles you can edit the name and description inline; for system roles those are read-only.

Below that, the app's capabilities are laid out as a stack of module cards (for example, RedFlare exposes Conversations, Agents, Dashboards, Workflows, Alerts, and Integrations). Each card lists that module's individual permissions as toggle pills - actions like View list, View, Create, Edit, Delete, Export, and more, depending on the module.

Working with permissions:

• Toggle a pill to grant or revoke that single permission. Every permission is independent - granting or revoking one never implies or changes another.
• A pill you've just granted is marked with a plus, and one you've just revoked with a minus, so you can see your pending change before saving. Already-granted permissions show a tick.
• Each module shows a running granted vs. not-granted count, plus All and Clear shortcuts to grant or revoke every permission in that module at once.

Saving changes

Your edits accumulate as a draft. A status note reads Unsaved changes while edits are pending and All changes saved once they're stored. Use Save changes to apply them, or Discard to roll back to the last saved state.

If you try to switch to a different role while you have unsaved edits, the console asks you to confirm before discarding them, so you don't lose work by accident. Deleting a custom role also asks for confirmation and can't be undone.

Settings

The Settings tab holds the app's data-policy defaults and other options.

The main control here is Default access - what happens for a user who has no applicable data policy. It's a dropdown with two choices:

• Permissive - no policy grants full access.
• Restrictive - no policy denies all access until a policy is assigned.

Because this is a high-impact change, switching the mode asks you to confirm first.

This default works hand in hand with the policies you build under Data policies - the policies decide who sees what, and the default decides what happens when no policy applies.