Each service contains a hierarchical collection of elements required to fulfill the service, e.g., a router, physical server, network adapter, virtual machine, etc.
The elements come from the element inventory — a single element can be re-used across multiple services (e.g., a core router or a DNS server).
Elements in a service are organized as a tree (reflecting their dependencies) with the root node representing entire service:
The element structure can be vastly different from line items in the product/product bundle. For instance, for a product “Mongo DB with 1TB storage”, the dependency tree may consist of a number of physical/virtual servers (e.g., for shards/redundancy), multiple storage arrays per each host, network connectivity between the hosts, WAN access/firewall, etc. In other words, services are customer-facing, while elements are network-facing.
The role of service elements is twofold:
|
Creating service elements
Service elements can be created as follows:
- When using Nextian quoting, service template can be specified in the Price Book Entry (PBE) — the template is used to create new service elements during order processing (if no template is specified in the PBE, the newly created service has no elements). This happens 100% automatically.
- Via Create Elements From Template action on service details.
- Fully manually using service elements related list.
| Important | While elements are stored in Element__c object records, service-element associations are stored in Service_Element__c object which is a junction object between the two with additional information about inter-element hierarchy within a service (an element can be reused in multiple services and can have a different placement in the element tree). |
