Service components and structure in the Dynamo Marketplace
What a service is in the Dynamo Marketplace
In the Dynamo Marketplace, a service represents a digital product that you can configure as a Provider and make available to Buyers through the Storefront.
From the Buyer’s perspective, a service is displayed as an item that can be viewed and purchased through the Storefront.
From the Provider’s perspective, a service is the result of multiple technical, commercial, and operational configurations required to create a complete service offering, publish it in the Marketplace, and make it available for purchase.
How services are organized
In the Dynamo Marketplace, publishing a service relies on several interconnected components.
The key concepts are:
- Service category and Sub category, which identify the category and type of service;
- Service class, which defines the technical service model;
- Marketplace Service, which represents the service offering configured by the Provider;
- Variant, which represents a specific combination of price-relevant attribute values within a Marketplace Service;
- Service Center and Data Center, which identify where the service is delivered;
- attributes, which define parameters, options, and information required or returned by the service;
- pricing, which determines the commercial model of the service;
- provisioning, which defines how the service is activated after purchase.
This structure separates the technical service model from its commercial offering, Storefront publication, and operational delivery. If you choose API-based provisioning, you must contact Dynamo directly to define the authentication method for accessing the APIs.
What a Service class is
The Service class is the technical model of a service. It defines the service structure and the attributes that can be used during configuration, purchase, and provisioning.
A Service class can be created by:
- using a predefined template;
- creating it from scratch;
A Service class can include:
- service category and subcategory;
- technical attributes relevant to configuration and pricing;
- parameters requested from the Buyer during ordering;
- attributes returned after provisioning;
- supported provisioning methods.
A Service class is not yet a purchasable service for Buyers; it represents the technical model used to create one or more service offerings.
What a Marketplace Service is
A Marketplace Service is a service configured by a Provider based on a Service class and intended for publication in the Dynamo Marketplace.
The Marketplace Service inherits its core structure from the Service class, including category, subcategory, and configurable attributes, while adding the commercial and operational settings required to make it available to Buyers.
A Marketplace Service can include multiple variants, each defined by a specific combination of price-relevant attribute values and associated with its own price.
In practice, the Service class defines the technical service model, while the Marketplace Service represents the configured and publishable service offering.
Service offering
A service offering is the way a service is presented, configured, and made available to Buyers in the Dynamo Marketplace.
A service offering can include:
- service name and commercial description;
- associated image and documentation;
- terms and conditions;
- Service Centers and Data Centers where the service is available;
- pricing model;
- duration, renewal settings, remedy period, and grace period;
- compliance and data processing information.
The same Service class can be used to create multiple service offerings with different commercial configurations, pricing models, Data Centers, or operational settings.
Service Center and Data Center
Service Centers and Data Centers identify the locations or delivery areas associated with services published in the Marketplace.
They are independent and reusable entities:
- they can be created before the Service class;
- they are not tied to a single Service class;
- they can be associated with multiple service offerings;
- they are required to create and publish a service in the Marketplace.
A Service Center represents the overall geographic or operational context, while a Data Center identifies a specific service delivery location or infrastructure.
Service attributes
Attributes define the information and parameters used to configure, purchase, deliver, or describe a service.
Attributes can be:
- predefined in Service class templates;
- added from the available attribute library;
- created as custom attributes;
- configured as required or optional;
- validated through rules, minimum/maximum values, or regular expressions;
- displayed only when specific conditions are met.
Attributes can be used in different stages:
- Service details, to define technical and commercial service parameters;
- Order configuration, to collect information from the Buyer during the ordering process;
- Output attributes, to display information returned after provisioning.
Price-relevant attributes, such as CPU, RAM, storage, or bandwidth, define the variants of a Marketplace Service. Each variant corresponds to a specific combination of values for these attributes and can have its own price. Others collect information required for provisioning, such as server name, username, SSH key, access URL, or IP addresses.
Buyer-visible information and Provider configurations
In the Dynamo Marketplace, service configuration includes both the information displayed to Buyers during browsing and purchasing, and the operational and technical settings required to manage publication, provisioning, and the lifecycle of the service offering.
From the Buyer perspective, the Marketplace displays:
- service name;
- description and key features;
- service category and type;
- associated Provider;
- available Data Centers or locations;
- pricing and purchasing options;
- available plans and options;
- commercial and contractual terms;
- compliance and personal data information;
- certificates and related documents made available by the Provider;
- information published by the Provider.
From the Provider perspective, you also configure operational and technical elements such as:
- Service class and attributes;
- Service Centers and Data Centers;
- pricing configurations;
- compliance information;
- service lifecycle and change management settings.
This separation allows you to distinguish between the commercial information used to present the service to Buyers and the technical and operational configurations required to deliver and manage it.
Service pricing models
In the Dynamo Marketplace, services can support different pricing models and billing methods.
The pricing model determines:
- how the service cost is calculated;
- when charges are applied;
- how the service is purchased or renewed by the Buyer;
- how one-time, recurring, or usage-based charges are handled.
Depending on the published service, you can configure models such as:
- Upfront, for services paid in advance;
- One-off, for services purchased with a single, non-recurring payment;
- Subscription, for services with recurring fees;
- Pay per use, for services based on resource consumption or usage.
The Price plan defines the common pricing terms of the Marketplace Service, while prices are defined for each variant based on its specific combination of price-relevant attribute values.
Pricing information is used by the Marketplace to display costs to Buyers, manage checkout and payments, calculate renewals, and apply the commercial rules associated with the service lifecycle.
Service provisioning and fulfillment
In the Dynamo Marketplace, provisioning and fulfillment refer to the activities required to activate and deliver a service purchased by a Buyer.
Provisioning
Provisioning represents the technical activation process and can include:
- resource allocation;
- activation of components and configurations;
- creation of service environments;
- generation of access or usage information;
- returning outputs such as IP addresses, URLs, credentials, or other technical data.
Fulfillment
Fulfillment represents the complete operational process that moves a service from an ordered state to a delivered and available state. It can include:
- order validation;
- provisioning activities;
- manual tasks or approval workflows;
- service status updates;
- communications and notifications related to service activation.
The Provider can provision services using either email-based provisioning or API integration.
With email-based provisioning, the request is forwarded to the Provider and processing can continue manually. With API-based provisioning, the technical integration must be validated by the Dynamo team to verify that the Meson integration operates correctly.
Publication and Storefront visibility
When you publish a service, it becomes available in the Marketplace Services section of the Provider dashboard.
Publication on the Provider side does not mean that the service is immediately visible in the Buyers’ Storefront. The service becomes visible in the Storefront after Dynamo adds it to the catalog.
The Published status indicates that the service has been published from the Provider side, but it does not indicate that the service has already been added to the Buyer catalog by Dynamo.
What to prepare before creating a service
Before creating and publishing a service in the Dynamo Marketplace, it is recommended that you prepare all commercial, technical, and operational information required to configure the service offering.
In particular, you should have:
- Service Centers and Data Centers where the service will be delivered;
- a Service class to use as the technical model;
- the service offering name and description;
- service category and subcategory;
- commercial information and descriptive content;
- service image and contractual terms and conditions;
- pricing model and commercial terms;
- any compliance, data processing, and operational requirement information.
If you choose API-based provisioning, you must contact Dynamo directly to define the authentication method for accessing the APIs.
