Idea ID: 2834168

Set UserOptions fields via REST

Status : Accepted
9 months ago

It has to be possible to set fields of UserOptions via REST.

At the moment it is possible to use a REST call to open a request for an offering without filling in the UserOptions, even if they are marked as mandatory.
In my opinion this is a major failure.
However, in my opinion it is not enough to prevent this, but it should also be possible to order an offering via REST, just like via the portal. This includes the specification of UserOptions.



  • Great news, this idea has been accepted on our product roadmap. Subscribe to receive updates. (This is not a formal commitment, and subject to change)

  • I like the idea and I agree this is a bug (perhaps design bug) and no enhancement request. There are much more API calls faulty or missing, e.g. the response of an API call to receive a request with its user options, all user options only contain their ids and not the display value. This should also be fixed.

  • Ideally, the REST API should be enhanced so that it becomes consistent with the way that user options can be accessed from within business rules (i.e. entity.UserOption.OptionName)


             "entities": [{
                       "entity_type": "Request",
                       "properties": {
                                "DisplayLabel": "Test Title",


                                        "OPTION1_c": "OPTION_1_VALUE",
                                        "OPTION2_c": "OPTION2_VALUE",
             "operation": "CREATE"

    Not directly related to this use case, but very similar nonetheless:
    The same could be done for complex properties (in the SACM area)


  • Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team.

  • Thanks for trying it out and confirming. We will be considering the point of making this 'officially' supported.