You can build any number of service request forms to support your existing service request and provisioning process. New service request forms are built in two parts: one for the service as a whole, which includes metadata that applies to all components, and a blueprint specific to each component in the service.
Design considerations
Do you need to present different organizations (or groups) with unique information? For example:
- Will users be allowed to choose where the service is deployed (the destination)?
- Does any "business process" data need to be tracked, such as project codes or ticket numbers?
- Will users be able to set expiry dates, or specify that a service will never expire?
- Will users be able to specify placement requirements for requested services? If so, you need to add placement attributes to service-level forms.
Best practices
- Tailor request forms according to how knowledgeable your users are, and how much freedom you want to grant them in customizing requested services. If you don't want to allow any customization, configure read-only forms.
- Include an expiry date on the form to enable lifecycle management.
Examples
Script examples of dynamic list usage
