When a template is applied to a request, this template can cause several custom fields to be added to the request. This happens when a UI extension is linked to the request template. In the past, it was always possible for any specialist who had access to the request to update the values of these custom fields. After a request was passed to an external provider, for example, specialists from this provider would be allowed to change what was specified in the custom fields.
This was not always desirable, though. If an external provider applies one of its own templates to a request from a customer, it is necessary for the provider to have the ability to fill out the custom fields. But when the customer used one of its request templates and then passed the request to an external provider, it would be better if the provider would not be allowed to change the information in the custom fields.
That is why specialists are now able the update the value of a custom field only when the request template – and therefore the UI extension in which the custom field is defined – is registered in the specialist’s 4me account, or in a support domain account that belongs to the same directory account as the specialist’s 4me account. In addition, specialists who can apply a request template that is registered in a trusted account (i.e. the 4me account of an external provider) can always update the custom fields that this template adds to a request, provided that the specialist is allowed to modify this request.
The result is that, when a specialist of an external provider opens a request that has a UI extension from one of its customers, the custom fields remain read-only in Edit mode.
Below is an example of a request in Edit mode with a UI extension that is read-only: