Service Catalogue guide

What it is

The service catalogue is where an MSP decides which services it sells, what it charges for them, and which of its clients can buy each one. It sits on top of the platform service catalogue: Solidlio publishes the master list with a cost price, and each MSP layers its own sell price, SKU and naming over it.

Concepts

Term	What it is
`PlatformService`	The master catalogue row Solidlio publishes. Carries `basePriceCents` (suggested retail) and `costPriceCents` (your floor).
`AccountService`	Your account’s version of a platform service: your sell price, optional custom SKU, name and description, an enable flag, and the technician skill levels required to deliver it.
`OrganizationService`	One client organization’s access to one of your account services, with an optional per-client price override.
Cost floor	`sellPriceCents` may not be below the platform service’s `costPriceCents`. Enforced on every write on both surfaces.
Margin	`(sell − cost) / sell`, price-based. Reported as `null` rather than infinity when the sell price is zero.

A managed client is a separate Account from the MSP that services it. That distinction is the single most important thing to understand here — see Granting services to clients below.

Two management surfaces

There are two places an MSP service can be edited, and they do different jobs. Knowing which is which will save you confusion.

The service editor cannot adopt a platform service, delete one, act in bulk, or grant anything to a client. The catalogue manager can. They operate on the same AccountService rows.

Roles and permissions

Role	Catalogue access
platform administrator	Full
MSP administrator	Full
MSP technician	Full
organization administrator	Full, own account only
power user	None (403)
`CUSTOMER`	None (403)

MSP technician ranks above organization administrator in the hierarchy, so that floor would lock a standalone account out of managing its own catalogue.

Clients do not reach these routes at all.

Walkthroughs

Adopt platform services into your catalogue

Go to Services → Catalogue (/msp/services/catalog).
Open the Add from platform tab. It lists every platform service you have not yet enabled. Services already in your catalogue are excluded.
Set a sell price per row. The form refuses a price below the platform service’s cost price and shows the resulting margin as you type.
Select the rows you want and choose Add selected.

Bulk enable applies the same validation as a single add: the service must be active and available to your tier, the price must clear the cost floor, and duplicates — both against your existing catalogue and within the batch itself — are rejected before anything is written.

Reprice or rename a service you already sell

Services → Catalogue → My catalogue.
Edit the sell price inline. The margin recalculates live and the field will not accept a value below cost.
Optionally set a custom SKU, name or description. These override the platform values wherever the service is shown to your clients.
Toggle Enabled to stop offering a service without removing it.

Remove a service

Use Remove on the row. The removal is refused outright when the service is in use:

a client organization is enrolled in it,
it has a marketplace listing (deleting it would cascade and destroy the listing and every subscription under it), or
a service order references it (the foreign key would be nulled, severing a sold order from the thing that was sold).

When removal is refused, the page offers to disable the service instead, which stops new sales without destroying history.

Grant services to clients

Go to Services → Clients (/msp/services/clients).
Pick a client organization.
Choose Grant access and select a service from your catalogue, or Grant entire catalogue to enrol the client in everything at once.
Optionally set a per-client price override on the grant. Without one, the client is billed your catalogue price.
Suspend pauses a grant without removing it; Remove deletes it.

Granting the whole catalogue is safe to re-run — services the client already has are skipped rather than raising an error.

Configuration

Setting	Where	Effect if unset
Sell price	Per account service	Required. Must be ≥ platform cost price.
Custom SKU / name / description	Per account service	Falls back to the platform service’s values.
Enabled	Per account service	Defaults to enabled.
Required / minimum / recommended skill level	Per account service	No skill constraint is applied.
Per-client price override	Per organization service	Client is billed the catalogue sell price.

Plan tiers

The service catalogue carries no plan gate. It is available on every tier, including Free. The only money-related plan limit anywhere in the catalogue is limits.maxContracts, which governs contracts, not services.

Troubleshooting

“Sell price cannot be below cost price” — the price you entered is under the platform service’s costPriceCents. The response includes both figures. This is enforced on the catalogue manager and, since this release, on the service editor’s PATCH as well.

A client’s Service Catalog page is empty — the client has no OrganizationService grants. Until this release the grant could not be created for a managed client at all (see Limits), so this was the normal state. Grant services at Services → Clients.

Removal refused — the service has client enrolments, a marketplace listing, or service orders. Disable it instead, or clear the dependency first.

403 on /available?accountId=… — the account id is not yours. A foreign account id and a nonexistent one return the same 403, deliberately: distinguishing them would confirm whether an account exists.

Limits and known behaviour

Two surfaces, one dataset. The service editor and the catalogue manager both write AccountService. They do not conflict, but there is no single unified screen.
Custom-service cost price is a seeded default. When you create a custom service, its cost is set to 70% of the opening price. It is not recomputed when you later reprice — if it were, the cost floor would move with the price and never bind.
Marketplace listings are not managed here. The catalogue blocks a delete that would cascade into one, but creating and editing listings is a separate surface.
Validation errors from these two routers use the service-wide { error, message, details } shape rather than the { error: { code, message } } convention used elsewhere.