Manage policies in the Console

Policy management is Console-only. Use Form for a structured definition, Code for the complete YAML or JSON definition, Flow for relationships, Matrix for Resource Policy action coverage, and Live Testing before release.

Choose the policy lifecycle

Policy type	Console lifecycle
Resource Policy	New Policy can create a custom resource policy. System resource policies are synchronized, editable, and not deletable from the Console.
Principal Policy	New Policy can create rules for one caller.
Derived Roles	New Policy can create reusable conditional roles. A resource policy must import and use them. Delete is not offered in the policies list.
Role Policy	Synchronized when an App Role is created. Its initial resource wildcard and action wildcard are broad; review and narrow them before assigning users. It is update-only in policy management and must not be created as a separate replacement for the App Role.

Prerequisites

• Select the target app and determine whether the policy is a custom createable type or a synchronized, update-only Role Policy or system-resource policy.
• Prepare one allowed and one denied Live Testing case before changing the definition.
• Open the existing policy in Code and copy its complete definition, so you can restore it if needed.

Create a custom policy

1. From Policies, select New Policy, then choose the policy type: Resource Policy, Principal Policy, or Derived Roles.
2. In Choose a Template, choose a template or select Start from Scratch. Remove actions and rules the application does not need.
3. Complete the policy in Form or Code, then inspect Flow. For a Resource Policy, also inspect Matrix.
4. Select Save to open Review Changes. Compare the complete definition, then select Save Changes to persist it.

Do not use this create flow for a Role Policy or a system-resource policy. Open the synchronized definition instead.

Replace the complete definition

Full-definition replacement

Save replaces the whole saved definition, and creates the policy if it doesn't exist yet. It first opens Review Changes; only Save Changes persists the replacement. Preserve the current complete definition before saving. If verification fails, restore the previous full definition and repeat the same review flow before rerunning both tests.

1. Open the intended policy and compare the preserved definition with the current Form and Code views.
2. For a system-resource policy, include every required action shown in the resource-action reference, or use the wildcard. A partial action set is rejected.
3. Before using an imported derived role, confirm that its derived-role policy and referenced definition already exist.
4. Inspect Flow and, for a Resource Policy, Matrix for unintended coverage. Review the full diff rather than assuming omitted fields survive.
5. Select Save. Invalid code format, an invalid policy structure, a missing required action, or an undefined imported derived role prevents Review Changes from opening.
6. In Review Changes, inspect additions, modifications, and removals, then select Save Changes.
7. Use Live Testing with one allowed and one denied caller/resource/action/attribute case.

Edit synchronized system policies

The policies list shows a system policy with a Read-only badge. That badge locks its identity fields and removes policy deletion; it does not lock its rules. Open the policy and use Form to add, edit, or remove rules, then use the same Save → Review Changes → Save Changes flow. Preserve every required system action and test both decision outcomes.

System resource policies cannot be deleted from the policies list. Derived Roles also have no delete action there. A Role Policy can display a list delete icon because it is not marked as a system resource policy, but do not use that icon: delete the owning App Role through the App Role workflow so memberships, descendants, Site Role links, and synchronized policy state are handled together.

Soft-disable an eligible custom policy

Use this workflow only for a custom Resource Policy or Principal Policy. Deleting a policy disables it: it stops applying immediately, and you can't restore it yourself.

1. Affected resource and cascade: Identify the full policy ID, the app, importing policies, derived-role references, and callers that currently depend on it.
2. Reversibility: The policy can't be re-enabled from the Console; to restore it, contact TaruviBase support.
3. Authorization: Confirm you are approved to change this production policy.
4. Backup or export: Copy the full definition from Code, and note the policy ID and one ALLOW and one DENY test result.
5. Confirmation: In Policies, select Delete policy, verify the exact name in Delete Policy?, then select Delete.
6. Success response and postcondition: Confirm the policy disappears from the active list and rerun the affected ALLOW and DENY cases. Stop if the observed decision does not match the approved postcondition.
7. Recovery: Contact TaruviBase support to re-enable the same policy ID, restore the preserved full definition if needed, and rerun both tests. Do not create a duplicate policy as a substitute.

Verification

You're done when the saved definition matches what you intended and Live Testing shows the expected allowed and denied decisions. A successful save doesn't confirm that related synchronized policies exist, so check them too.

Restrict Console access to the people who should change policies.