Idea ID: 2854070

Transferring UserOptions from the request to all records opened from this request

Status : Waiting for Votes
Waiting for Votes
See status update history
5 months ago

When creating a record (e.g. Incident, Change etc.) from a request (no matter if manually or by an automated task) the specific user options have to be displayed in the target record.

Tags:

Labels:

SMAX
  •  

    You are right. In the first tenant there seems to be a bug, because the UserOptions tab is not displayed in the Incident, but now I have tested it again in another tenant and there the UserOptions appear.
    In any case, this is already very good. If there would be User Options in every module by default, that would be great.
    Especially for tasks and new modules.

    Furthermore, this no longer works if you use models. The settings in the model then overwrite the UserOptions that were taken from the request. There should be a way to combine this.

  • I implemented this for the Incident process, and the user options just got displayed. There was nothing to be added on the form.

    You just need to make sure that both UserOptions and UserOptionsName are copied.

  • Hi ,

    thanks for the tip, I tried that, however the UserOptions are not shown to me anywhere. How do I get them displayed, like in the request tab catalog offering?

  • This can actually already be done for those related records that support user options.

    You just have to update the rule that creates the related record to also copy the two following fields:

    • UserOptions
    • UserOptionsName

    e.g. for Request to Incident escalation based on "Service Impact" checkbox, add the two fields shown in green.

    Rule ID: CreateIncident (in Request / IT Support)

    If ${entity.ServiceImpacted == true && current_update.ServiceImpacted.IsChanged && entity.IncidentCausedByRequest == null}
    Create new related record with relationship IncidentCausedByRequest and 
    UserOptions: ${entity.UserOptions}
    UserOptionsName: ${entity.UserOptionsName}
    Description: ${entity.Description}
    RegisteredForActualService: ${entity.RegisteredForActualService}
    Category: ${entity.Category}
    RegisteredForLocation: ${entity.RegisteredForLocation}
    ContactPerson: ${entity.RequestedForPerson}
    DisplayLabel: ${entity.DisplayLabel}
    ExpertAssignee: ${entity.ExpertAssignee}
    RequestedByPerson: ${entity.RequestedByPerson}
    OwnedByPerson: ${entity.OwnedByPerson}
    ImpactEnd: ${entity.ImpactEnd}
    PreferredContactMethod: ${entity.PreferredContactMethod}
    ImpactStart: ${entity.ImpactStart}
    ServiceDeskGroup: ${entity.ServiceDeskGroup}
    ExpectedResolutionTime: ${entity.ExpectedCompletionTime}
    Priority: ${entity.Priority}
    ImpactScope: ${entity.ImpactScope}
    ExpertGroup: ${entity.ExpertGroup}
    Urgency: ${entity.Urgency}
    I have tested this with Incidents, but it should work also with Changes and Releases (which both have UserOptions and UserOptionsName fields)
  • 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.