--- title: Ordering Services slug: ordering-services docTags: createdAt: 2025-06-11T20:26:21.329Z --- The following section outlines the options for controlling how services are ordered. ## Security The ability to order services is controlled by the 'ADD' access right on the service. Users must have 'ADD' and the target user must have 'USE' rights to be able to order a service for the user. ## Forms and Arguments Services can also gather additional information that can be used to control the service. This information can be used during automated provisioning or passed to an external process via the order process. ### Arguments The 'Arguments' parameter is a template for the data being gathered and in a similar way to Tasks provides a security mechanism for controlling the data that can be passed to the service. The following is an example of an 'Arguments' parameter for a service that is expecting to specify an approval limit for the service. \ \   \   \ \ ### Web.Form A 'Web.Form' parameter is then specified to create a form to display to the user to gather the information. A Web.Form on a service is expected to be at least able to render itself for HTML Display Only mode. Therefore, there are limitations on the the controls that can be used. Please see the Web Portal Controls for more information. ### Legacy Services Services that were created for previous versions will still operate in V5. However, there are some limitations. In previous versions (ie pre V5) the web form parameter was called 'WebForm' (not Web.Form). This parameter is still valid, however, this forces the service into 'Legacy' mode. The web form will not be rendered as HTML and no difference information is available. The Service also expects an old style 'OrderDescription' parameter to be specified to render the arguments as text for display to the user and sending via any order process. ## Expiry and Effective Options Allow services can have an optional effective date and an option expiry date. There are Service Flags that can completely disable these options if required. There are a number of extended options that can also be specified to control the expiry information. These options are stored in a parameter called 'ExpiryOptions'. Valid options for the ExpiryOptions parameter are below. These options may be combined by listing them seperated by a ',' or ';'. | | | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | **Description** | | All | Allow all valid expiry options. This is the default value if not specified. | | None | Do not allow expiry to be set. | | Permanent | Allow no expiry to be an option | | Date:\[Max Time] | Allow a date to be specified. The optional argument identifies that maximum/default date that can be specified. The argument can be an expression or string resolving to any valid Activate timespan value (ie +30days) Examples: Date:+30days                          - allow any date in the next 30 days to be specified Date:=//Service/MaxExpiry       - get the value from a parameter on the service | | Auto:\[Time] | This is similar to the last option except that the user cannot specify the date. The service will automatically expire at the specified time. This is useful for services that you wish the user to periodically reapply for. | | Role:\[Type] | This option allows one of the users roles to be selected. The default option for the type is 'Departments'. This will look up the current users 'Departments' roles and show them. The \[Type] may also be an expression resolving to a list of roles. |