Policy Center basics

Policy Center is the portal control plane for recurring TvRMM behavior. Use it for settings that apply consistently across a tenant, organization, sub-organization, target profile, or selected endpoint exception.

In the portal, open Administration → Policies or go directly to /ui/policies. Endpoint detail pages show the endpoint's Effective Policies panel and link back to Policy Center for changes.

What belongs in Policy Center

Policy Center is the right place for recurring behavior such as:

• audit and inventory cadence;
• log collection scope and retention;
• patch deployment and patch approval behavior;
• agent update behavior;
• app/package provider allow or block policy;
• script policy;
• monitoring and automation defaults;
• remote access policy.

Policy Center policy pages use these deployed portal routes:

Policy type	Portal route
Audit and Inventory	/ui/policies/audit_inventory
Log Collection	/ui/policies/log_collection
Patch Deployment	/ui/policies/patch_deployment
Agent Update	/ui/policies/agent_update
Patch Approval	/ui/policies/patch_approval
App/Package Provider	/ui/policies/app_provider
Script	/ui/policies/script
Monitoring & Automation	/ui/policies/monitoring_automation
Remote Access	/ui/policies/remote_access

Starter policies

New tenants and organizations can include conservative starter policies plus unassigned examples. These are intended to make safe defaults visible without silently turning on risky behavior.

Examples may include scan-only or manual patch baselines, record-only monitoring, log collection examples, script examples, app/package provider examples, and remote access examples.

Roles and operating-as

• Viewer or higher can view policy lists and effective policy state for visible organizations and endpoints.
• Operator can run endpoint actions where the endpoint, policy, and workflow allow it, but operator cannot save Policy Center assignments.
• Admin can create or edit most policy bodies and can save or remove direct organization, sub-organization, and endpoint assignments for organizations they administer.
• Owner is required for tenant-baseline assignment changes.
• The operating-as selector can lower your effective role. If you are capped below the required role, the portal treats the action as unavailable.

Support users and platform administrators still need an allowed customer context before viewing or changing tenant policy.

Assignment levels

Policies can be assigned at different levels depending on policy type and tenant structure:

• tenant baseline;
• organization;
• sub-organization;
• endpoint exception;
• target-profile filtering inside policy bodies where the policy type exposes it;
• explicit No policy to block inheritance for that policy type.

Endpoint assignment is an advanced exception path. Prefer tenant baseline, organization, and sub-organization assignments unless a specific endpoint requires different treatment.

Target profiles narrow a policy body's effective reach. If a policy is assigned to a scope but the policy's target profile excludes an endpoint, that endpoint does not receive that policy.

Create, edit, assign, and remove

To create or edit a policy:

1. Open /ui/policies.
2. Choose the policy type.
3. Select Create Policy or open an existing policy with Edit.
4. Review enabled state, policy details, and the operational workflow affected by that policy type.
5. Save the policy with an admin-or-higher effective role for the relevant scope.

To assign a policy:

1. Open the policy type page.
2. Use Assign on the policy row or the assignment panel.
3. Select a known target or enter the target level and ID.
4. Choose Policy and the intended policy.
5. Save the assignment.

To remove a direct assignment:

1. Open the policy type page.
2. Open the row's direct assignment chip.
3. Use Remove for one scope or Remove all for every direct assignment on that policy.

Removing a direct assignment restores inheritance from the next higher applicable scope. It does not delete the policy body unless you also use the policy delete action.

Explicit No policy

No policy is a direct assignment state. It intentionally blocks inherited policy for that policy type at the selected target.

Use No policy when a scope must opt out of inherited recurring behavior. Treat it as an operational exception: patch scans, patch installs, log collection, monitoring, scripts, agent updates, or remote access can stop for that scope if the blocked policy was the only effective policy.

To recover inheritance, remove the No policy assignment or replace it with a direct policy assignment.

Expected results and evidence

After a policy change:

• Policy Center shows direct assignment counts and direct assignment targets on the policy row.
• Endpoint detail shows Effective Policies with inherited tenant, organization, sub-organization, and endpoint policy state.
• The affected workflow uses the new policy after the endpoint checks in, refreshes effective policy, or reaches the next scheduled run for that workflow.
• Tenant export data includes policy assignment records and redacted policy assignment event records for customer review.

What to check before changing a policy

Before editing or assigning a policy, confirm:

• the tenant and organization scope;
• the endpoint type and support state;
• whether the policy is enabled;
• whether the policy is assigned or only an example;
• whether a lower-level assignment overrides the inherited policy;
• whether an explicit No policy is blocking inheritance;
• whether a target-profile filter excludes the endpoint;
• whether the action also has endpoint, role, license, helper, relay, or platform support gates.

Rollback, troubleshooting, and escalation

For a mistaken assignment, remove the direct assignment or assign the previous policy at the same scope. For a mistaken No policy block, remove the No policy assignment to resume inheritance.

If a workflow does not behave as expected, check the endpoint's Effective Policies panel first. Then confirm your effective role, operating-as cap, endpoint support state, target-profile match, and whether the endpoint has checked in since the policy changed.

Policy enables a workflow; it does not override endpoint support limits. For example, remote desktop also requires a supported direct or linked real agent, helper capability, license state, relay readiness, and sufficient user role.

Escalate to support when the policy row, effective policy panel, and endpoint action state disagree after a fresh endpoint check-in. Include the tenant, organization, endpoint, policy type, visible effective source, and the user role shown by the operating-as selector.