Service Portfolio - Admin Guide

The Service Portfolio is a view on top of the CMDB, not a separate entity. Services are CIs of type='business-service' or type='service' that contain other CIs via the contains relationship. The portfolio surface adds health rollup (combining worst member status with active Major Incidents touching members).

Defining a service

Use create_ci (MCP) or POST /api/cmdb/cis with type='business-service' (customer-facing offering) or type='service' (internal technical service).
Set criticality, owner, environment, description.
Use add_service_members (MCP) or POST /api/service-portfolio/:id/members to bulk-wire the backing CIs. Sets contains on the service + member_of inverse on each member.

Recommended: model business services at the level your CFO or CEO would recognize ("Customer Order Portal", "Employee Self-Service", "Vendor Payment Pipeline"). Below that, model technical services if you want to layer infrastructure dependencies more granularly.

Health classification

Health	Triggered by
🚫 major-outage	Any active Major Incident touching the service CI or any member CI
🔧 maintenance	Any member CI has `status='in-maintenance'`
❓ unknown	Service has 0 members OR service status is `retired`
✅ healthy	Has members, no MIs, no maintenance, not retired

The portfolio listing is sorted with outages first, then by criticality desc - so executives see the worst news at the top of the dashboard.

Service status page

The status page is a published, read-only rollup of the portfolio intended for an audience that can't (or shouldn't) see the full CMDB - end users, business stakeholders, or external customers. It reuses the same health classification described above, surfaces current service state at a glance, and lists scheduled maintenance windows so consumers know when a dip in availability is planned rather than an outage.

Current state per service. Each business-service / service CI is shown with its rolled-up health badge (major-outage / maintenance / unknown / healthy), so viewers see the same worst-news-first ordering without any infrastructure detail.
Maintenance windows. Member CIs set to status='in-maintenance' flip the service to the 🔧 maintenance state on the status page; pair this with a change-request window so the planned start/end is communicated rather than read as an unplanned outage.
Active incident banner. An active Major Incident touching the service or any member CI drives the 🚫 major-outage state and is the signal a status page should headline first.
Internal or public consumption. Internal viewers use the in-app portfolio surface (Viewer+); for an external-facing status view, publish through the same health rollup without exposing CI internals.

Prerequisites: services must be defined and wired (see Defining a service), and the underlying CMDB plus Major Incident data must be present for health to classify accurately - without active MIs or member status, the page falls back to healthy. Reading the status rollup requires Viewer+; declaring maintenance (via member CI status) or Major Incidents requires Admin.

REST endpoints

GET /api/service-portfolio (Viewer+) - all services with member rollup, max-criticality, worst-status, active MI impacts, health classification
GET /api/service-portfolio/:id/health (Viewer+) - recursive health for one service. Walks contains outbound to enumerate ALL member CIs (including nested), counts by criticality + type, lists active MIs touching any member
POST /api/service-portfolio/:id/members (Admin) - bulk-add CIs as members. Up to 100 per call. Idempotent. Auto-maintains contains + member_of inverse.

MCP tools (3, HTTP + stdio parity)

list_service_portfolio - executive view with health rollup
get_service_health - drill-down for one service (use during exec brief during an incident)
add_service_members - bulk-wire infrastructure to a service

Pitfalls

Service Portfolio is a CMDB view, not a separate entity. Don't try to query a Services container - services ARE CIs. The endpoint filters to type business-service or service.
Health rollup requires CMDB AND Major Incident data. Without active MIs (or without affectedCiIds on declared MIs), the health classification falls back to maintenance / healthy based on member status only.
Nested services walk recursively. If service A contains service B which contains 50 CIs, get_service_health on A returns all 50 CIs. This is intentional - exec dashboards want full transitive scope.