Plans and policy templates

Plans decide what a customer can see. Policy templates decide what their devices start with. Together they're the partner's productization layer — the difference between bespoke consulting on every deal and a repeatable onboarding motion.

The plan lifecycle

The Plans list shows each plan's Name, Version, Created At, Updated At, Updated By, and Assigned To — and every column sorts, because at scale you'll want "what changed most recently" and "what's most widely deployed" on demand.

Authoring and cloning. New plans start from a clone, the same philosophy as the policy engine: begin from something already valid rather than an empty form. Clone a proven plan, rename it, adjust the module gates, and you have a new commercial tier without touching a working one.

Versioning. Plans carry versions as they change, with the last editor recorded. When a customer asks why a module appeared or vanished, the version and updated-by fields are your first stop.

Assignment. The assign flow is a multi-select over your customer accounts, showing what's already assigned and letting you add more, with a confirmation step before it commits. This is the mechanism from S2 made concrete: assigning a plan is what actually switches modules on and off in that tenant's console.

Deletion is a separate, gated capability — and the reason to check Assigned To first. That column is your blast radius indicator: editing or deleting a plan sitting on forty accounts changes forty customer consoles.

The professional habit: never edit a widely-assigned plan to serve one customer's request. Clone it, change the clone, assign the clone to that customer. You keep the original stable and gain a new sellable tier.

Policy templates

Templates are reusable policy configurations that live at the partner level rather than inside one customer's console. The list shows Template Name, Type, Version, Exported By, and Date Exported — the export lineage telling you where a template came from and who produced it.

The workflow this enables is the one that wins deployments: instead of configuring a new customer's kiosk policy from a blank slate, you carry your proven configuration — built once, refined across deployments — and seed their tenant with it. Clicking a template opens it in the same policy detail view you know from the customer console, so there's no second interface to learn.

Two capabilities here are separately gated: updating templates and deleting policies. As with plans, a missing button is usually your org's configuration.

Why this is the partner's leverage

A customer evaluating two partners sees the same WeGuard underneath. What differs is how fast you get them running and how sane their configuration is on day thirty. A partner with a curated plan ladder and a template library onboards a tenant in minutes with a configuration that's already survived contact with other customers. A partner without them rebuilds every deployment by hand and inherits every mistake twice.

That library is your intellectual property. Build it deliberately.