Relationships

Services are joined by relationships, each of a kind: “Web shop depends on Payments”, “Web shop uses Notification delivery”. Together they are one graph that the desk follows for health, for The whole chain on a service's page, for the Dependency map, and for what a change can touch.

Dependencies made before relationships came carry over as Depends on, with the date each was added.

The kinds

Kind	The other way	Spreads trouble	Joins
Depends on	Needed by	Yes	Services; with the CMDB plugin, also a service or CI to a CI
Uses	Used by	No	Services; with the CMDB plugin, also a service or CI to a CI
Runs on	Runs	Yes	A service or CI to a CI (CMDB)
Hosted on, Contains	Hosts, Part of	Yes	A CI to a CI (CMDB)
Connects to	Connected from	No	A CI to a CI (CMDB)

The last three rows and the CI ends need the CMDB plugin's configuration items.

Spreads trouble means that when the other end has a problem, this one is at risk through it: “At risk through PAY”. Use Depends on when an outage really passes through, and Uses when the service keeps working without the other (it sends fewer notifications, say). An offering is at risk when its service has trouble; trouble on an offering never reaches its service. Health, a service's whole chain, a change's impact and the Dependency map all go this one way.

Kinds that spread trouble can't go round in a loop, even when the loop mixes kinds. The desk refuses one and names it: “That would make a loop, so trouble would go round in circles: SHOP → PAY → SHOP”.

On a service's page

• Depends on and Needed by show its dependencies on other services, set under Edit.
• Other relationships (Relationships when the CMDB plugin is on) shows the rest, both ways: “Uses NOTIFY”, “Used by SHOP”. Add joins it to another service of the organization, or with the CMDB plugin to a configuration item: pick the Kind, the other end and an optional Note. The bin removes a relationship that starts from this service. Map opens the Dependency map centred on it.
• The whole chain follows every kind that spreads trouble, through configuration items too, and offerings: what a service affects takes in its offerings, and what an offering relies on takes in its service.

Who does what

Who	Can
Whoever may edit a service (its owner, service.write or service.settings)	Add and remove the relationships that start from it.
service.settings for the whole organization	Add, change, archive and delete the organization's own kinds.
Everyone who can see the service	See its relationships; an end they can't see shows as Hidden (no access).

Both ends are always in the same organization.

Kinds of your own

Under Service Configuration → Settings → Relationships, Built-in relationships lists the kinds that are the same everywhere, and Your relationships the organization's own. Add kind adds one, such as “Backs up” / “Backed up by”:

Setting	What it does
Name and The other way	How it reads from each end: WEB backs up DB, DB backed up by WEB.
Description	Optional. Shown when someone picks the kind.
Spreads trouble	Whether trouble at the other end puts this one at risk.
Joins	Services to services, a service to a configuration item, or configuration items to each other (the last two with the CMDB plugin).

Each name is used once in the organization. Once relationships have a kind, whether it spreads trouble and what it joins can't change. A kind in use can be archived: its relationships stay, and it can't be picked for new ones. A kind nothing has can be deleted. The built-in kinds can't be changed.

History and evidence

A relationship added or removed is a change to the service it starts from: it is in that service's History, and in the audit log with who did it and when. The graph also keeps every relationship added and removed, so the Dependency map can show what was joined to what on any past date. Kinds and environments added, changed and deleted are in the audit log.