ODOE Platform Administration And Settings

Platform Administration And Settings

Administrative control surface for users, roles, AI policy, knowledge governance, notification rules, and service ownership across the ODOE platform.

Administrative Control

Control the platform without burying governance in back-end configuration.

A mature service platform needs visible, governed settings for who can see what, what AI can access, how knowledge is approved, where alerts are sent, and who owns each service. The admin surface should make policy understandable, auditable, and hard to drift accidentally.

Audience: platform admin, IT leadership, governance Use: configuration control + policy stewardship Connected to: AI Routing + Knowledge + Audit
governed
124

Active users with role-based access

policy managed
6

AI policy bundles in force

awaiting review
3

Admin changes pending approval

coverage
93%

Services with named owner and notification rule

Administrative Domains

Each configuration area should have an owner, review cadence, and audit trace.

Change-controlled
Domain What It Controls Owner Review Pattern
Users and roles Audience visibility, admin rights, service-owner permissions, approver scopes Platform admin Monthly access review
AI policy and routing Eligible tiers, blocked actions, approved sources, escalation rules IT leadership + governance Quarterly policy review
Knowledge governance Published source sets, owner approval, confidence thresholds, review dates Knowledge owner 30-day source review
Notifications and escalation Stakeholder updates, bridge notifications, approver nudges, vendor alerts Service desk lead Monthly service test
Service ownership Catalog ownership, dependency accountability, budget and reporting responsibility IT manager Quarterly service review

Settings Panels

Representative controls from the admin experience.

Users And Role Management

Control who can view, approve, configure, and administer across the platform.

Role model

Executive, stakeholder, service owner, IT operator, platform admin

5 roles
Privileged access

Separate admin privilege from daily operator visibility

Enabled
Review cadence

Quarterly role attestation for managers and admins

90 days

AI Policy Controls

Define what the models can access, which tiers are allowed, and what actions are blocked.

Default AI tier

Lowest-cost eligible tier for routine demand

Tier 1-2
Blocked actions

Approvals, service-impacting changes, autonomous sends, unsourced policy output

4 classes
Write-back logging

Every governed AI action records source, tier, and operator context

Required

Knowledge Governance

Keep self-service answers tied to approved, current, and owned content.

Published source sets

Policies, FAQs, service definitions, runbook excerpts, approved guidance

18 sets
Source expiry

Flag stale content before it remains eligible for AI retrieval

30 days
Owner approval

Knowledge owner approves publication and retirement

Required

Notifications And Service Ownership

Make accountability and operational communication explicit.

Stakeholder messaging

Severity-based notification templates and approval path

Governed
Vendor escalation alerts

Auto-remind owner when response SLA or bridge cadence slips

Enabled
Service owners

Each published service has named operational and business ownership

93%

Recent Administrative Change Activity

Settings changes should behave like governed work, not hidden configuration drift.

Yesterday

Raised required confidence threshold for policy-answer routing after stale-source review.

2 days ago

Added named backup owner for Teams workspace services and linked escalation notifications.

Last week

Restricted premium AI tier access to approved incident command and leadership scenario paths.

Last week

Completed quarterly admin-role attestation and removed two expired platform-admin grants.

If administration lives only in hidden configuration, the platform becomes hard to govern. Good admin design makes control visible, reviewable, and accountable.