Service Catalog
The Service Catalog turns the abstract idea of "what we offer" into a concrete, governed menu inside ServiceCore. Each catalog item represents a service offering with everything needed to fulfil it built in: its own request form, its approval path, and its target SLA. Because that structure lives on the item itself, a request submitted from the catalog arrives complete and pre-classified, then routes itself to the right team without a triage step in between.
Built for the way service catalog should work
The Service Catalog turns the abstract idea of "what we offer" into a concrete, governed menu inside ServiceCore. Each catalog item represents a service offering with everything needed to fulfil it built in: its own request form, its approval path, and its target SLA. Because that structure lives on the item itself, a request submitted from the catalog arrives complete and pre-classified, then routes itself to the right team without a triage step in between.
Items are organized into categories and subcategories so the catalog stays navigable as it grows from a handful of services to hundreds. Visibility rules govern who sees what: each item, category, or whole view is scoped by user, role, organization, or location, so a department sees only the services that apply to it and nothing it can't actually order. The same catalog can present a user-facing request view alongside a broader service-provider view of the underlying offerings, keeping one source of truth instead of parallel spreadsheets.
The catalog is the front door to ServiceCore's fulfilment engine rather than a static list. Selecting an item creates a Request Management record from the item's form template; built-in approvals fire before work begins; the item's SLA target starts the clock in Service Level Management; and the predefined Workflow behind the service fans out the right tasks to Task Management on every run. Self-service ordering is exposed through the Self-Service Portal, where the same visibility rules decide what each requester can browse and submit.
Because all 29 modules share one data model, a catalog item is not an isolated form but a reusable definition referenced everywhere it matters. Update an offering's form fields, approval stage, or SLA once and every future request inherits the change; reporting in Analytics reads the same item records to show demand, fulfilment time, and SLA attainment per service. The result is standardized, repeatable service delivery where the catalog defines the contract and the rest of the platform executes against it.
- Governed service catalog
- Item-level forms
- Built-in approvals
- Per-item SLAs
- Categories & visibility rules
- Self-service ordering
What you can do with it
Governed catalog structure
Organize service offerings into categories and subcategories so the catalog stays navigable and consistent as it scales from a few services to hundreds.
Item-level request forms
Attach a dedicated, dynamic form to each catalog item so requesters supply exactly the fields that service needs and submissions arrive complete.
Built-in approval paths
Configure single or multi-stage approvals per item that fire automatically before fulfilment begins, with full context shown to each approver.
Per-item SLA targets
Set a fulfilment SLA on each offering so the clock starts the moment a request is created and breaches are surfaced through Service Level Management.
Visibility rules
Scope items, categories, and entire catalog views by user, role, organization, or location so each audience sees only the services it is entitled to.
Predefined fulfilment workflows
Bind a standardized workflow to each item that automatically dispatches the right tasks to the right teams on every order.
Why teams adopt it
Fewer triage steps
Requests arrive pre-classified with the right data, approvals, and routing, so the service desk spends less time sorting and reassigning tickets.
Standardized delivery
Every order of the same service follows an identical form, approval, and workflow, producing repeatable quality instead of ad-hoc handling.
Controlled, relevant access
Visibility rules keep the catalog tailored to each audience, reducing wrong submissions and shadow requests through unofficial channels.
Single source of truth
One catalog definition feeds the portal, fulfilment, SLAs, and reporting, so a change made once propagates everywhere without parallel lists.
Where it fits
Employee onboarding
HR and IT publish a new-hire onboarding item whose form collects role and start date, then routes provisioning tasks across teams automatically.
Software access requests
Users order an application from the catalog, the item's manager-approval stage runs, and access is granted under a defined fulfilment SLA.
Hardware procurement
A laptop or peripheral request captures model and cost-center on its form, triggers budget approval, and opens the procurement workflow.
Cross-department ESM services
Facilities, Finance, and Legal expose their own offerings on the same catalog, each scoped by visibility rules to the audiences they serve.
Common questions
The Service Catalog is where you define and govern service offerings, including each item's form, approvals, SLA, and visibility rules. The Self-Service Portal is one of the channels that presents those items for ordering. The catalog is the source of truth; the portal renders the user-facing request view, and the catalog's visibility rules decide what each requester can browse and submit there.
Part of these solutions
Related modules
See Service Catalog in action.
Book a demo and we'll show service catalog working alongside the rest of the platform — on one shared data model.