Configure Service Catalog items
Catalog administrator rights. Target-related functionality depends on enabled Configuration Management, operating view and supported target types.
The Service Catalog is a controlled collection of requestable actions. A well-designed Catalog Item explains what users can order, captures the information needed to deliver it and sets the defaults and checks used by fulfilment staff.
Before you start
Open the separate Service Catalog entry in ExpertHub. Use its search, Active/Inactive filters and pagination to find existing definitions before adding another. Plan the intended action, fulfilment team, questions, approvals and technical scope.
Steps
- Choose Add catalog item or edit an existing item. Enter a clear name, description and browsing category.
- Set Active for whether new Requested Items may use it, and Visible for whether it appears in normal self-service browsing.
- Choose the fulfilment type that matches the implemented process. Link an Employee Profile for applicable onboarding/offboarding flows.
- Set the Service, optional Service Offering and default assignment group. The Offering must belong to that Service and cannot be specified without one.
- Configure any required supported target and Change policy. Review the exact Change gate behaviour before relying on it for governance.
- Choose whether manager approval, staff approval, both or neither is required.
- Save the item, then manage its intake fields once the item has been created.
- Add an optional PNG icon within the documented 2 MB limit. Review any separate ServiceHub tile icon and target association.
- Test the item through ServiceHub and inspect the resulting Requested Item's answers, requested-for person, assignment, approvals and targets in ExpertHub.
Expected result
The item provides a clear intake path and consistent service context for individual Requested Items. Staff can see the submitted answers and work the resulting deliverables.
Design the intake questions
The current field manager offers Text, Text area, Employee picker and Date. Set a clear label, required flag and display order for each field. Employee picker replaced the earlier separate onboarding/offboarding picker; older data can still contain User picker definitions.
Employee selection is omitted when the requested-for person is already provided by the staff workflow, and is shown through Requested for rather than repeated as an ordinary answer. Other captured field values remain associated with each Requested Item. Avoid casually deleting or repurposing questions already used by active or completed requests.
Supported targets and environment
The documented functional target choices are None, Service Offering, Service Instance and CI. CI and Service Instance targeting capture the selected component and its environment, which feeds Production-only Change gating. Configuration-connected targeting depends on the relevant capabilities and permissions.
Business Application, User, Group and Location target options are not fully enforced implementations. Do not present them as working target validation or assume that selecting them produces CI-level controls. Environment-dependent policy checks need accurate supported target context.
Active, Visible and historical use
Active and Visible are separate controls. Hiding an item does not disable it for new orders; deactivating it prevents new Requested Items. Review direct links and tiles as well as catalog browsing when retiring an item.
Deletion is blocked when Requested Items still reference the definition. Prefer deactivation or hiding for obsolete definitions, preserving historical request links and their submitted answers.
Important behaviour
Fulfilment-type labels do not guarantee external orchestration. Conditional Change policy is advisory, and Standard Change does not auto-generate a template-based Change. The enforced Change gate checks a link, not the linked Change's approval state. Test a real request path before making a new item widely available.