Skip to main content

Governance and release

Policies can protect an app, page, component, resource, query, action, field or row. A policy names the capability, subject match and optional structured condition; the host may use the default evaluator or provide its own adapter.

const policies = [{
  id: 'finance-approver',
  name: 'Finance approvers',
  effect: 'allow',
  level: 'approve',
  scope: 'action',
  target: 'approve-adjustment',
  subjects: {groups: ['finance']},
}]

PermissionSimulator makes the effective decision visible before release:

import PermissionSimulator from '@zuilib/builder/permissions'

<PermissionSimulator
  app={candidate}
  target="approve-adjustment"
  initialSubject={{id: 'maya', groups: ['sales']}}
/>

At runtime, denied pages disappear from navigation, denied nodes do not render, and denied resources or actions never reach their executors. Permission denials are telemetry events, so authorization problems are operationally visible.

Release gate​

Run registry-aware validation against the target environment before publishing:

const issues = await validateAppForPublish(candidate, registry, {
  environment: 'production',
  strict: true,
})

if (issues.some((issue) => issue.severity === 'error')) {
  throw new Error('Release blocked')
}

PublishDialog captures a version name, notes, target environment and publish targets. Save the composed AppSpec as an immutable AppVersion, not just the patch list. That makes restore, diff, audit and reproducible deployment simple. Use ZUI Cloud Config Store when those immutable app configurations need hosted ownership, access grants, and head-version resolution; a deployment pipeline remains responsible for selecting and releasing an approved head.

zui app check app.json --environment production --strict
zui app diff released.json candidate.json
zui app diff released.json candidate.json --json

Production environments can require approval independently from development or staging. Publish targets describe where a validated version is intended to run; deployment credentials and implementation remain host-owned.

Operational health​

The runtime emits app/page opens, resource and action runs, failures, denials, state changes, component/filter use, exports, AI interactions and abandoned forms. computeAppHealth(events, issues) turns that stream plus validation into latency, success-rate, usage and incident summaries rendered by AppHealth.

The workflow package completes the operational loop: approval controls, writeback forms, scenarios, comments, audit timelines, task queues, record detail and run history are ordinary registered view types and therefore remain usable in the renderer, builder and AI vocabulary.