# Customer Request Type Synchronization does not work

**URL:** <https://community.exalate.com/t/customer-request-type-synchronization-does-not-work/4385>\
**Category:** General Questions\
**Tags:** exalate, customfields, migrated\_question, onpremise-jira-serve\
**Created:** [November 4, 2024, 6:53am UTC](https://community.exalate.com/t/customer-request-type-synchronization-does-not-work/4385 "2024-11-04T06:53:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![xl8bot](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/xl8bot/32/324_2.png) [@xl8bot](https://community.exalate.com/u/xl8bot)\
**Post date:** [November 4, 2024, 6:53am UTC](https://community.exalate.com/t/customer-request-type-synchronization-does-not-work/4385/1 "2024-11-04T06:53:05Z")

</div>

_Originally asked by Dominik Blum on 12 October 2020 [(original question)](https://oldcommunity.exalate.com/questions/20119941)_

* * *

Hi all,

We want to synchronize the customer request type from system A to system B, but instead of setting the new customer request type only the old value is removed in system B.

I used [log.info](http://secure-web.cisco.com/1DZsdZ-NORoCNL7l5uKu25WVv-YuJHQioHl7YVxxW9TK1xnLK4ZsqeY4dUTORnqKOpoBUyXkDLAeYQBsv8xJqmYsxVxzJM_Xi_4aTgFTo-AiYl1d94skWF5q2VZwFBOXjpfLkOBNRiYVSN96lpC6Hs2gJe5i4CgA4F6QOrTGA4oBbLng35Lw7b-nBY5XmJq2UwdZRpNWs9TVA2EAh7QlmTtng4lU7jM_SNnx3jiW_oj7FblyRsA2G8FhZvuZXvWjXWv3QCAHUaWlgIme2Rn256GWun8_lcNT7vEmA4HSMVyTRn5XzQ35pEXq9g9mB0AZh_DrjNcwTDAA0veOnrvVeQE80fwQ5iWwW0WJK9QEd41jGG2ZZwhQtwiRnooJIQIARYma4cXbUveyEXf9z7VcLv5LDKxw_lsfoCySYHVmfpxndj7wH-o6tHYTogeG1nPXugnNOTbUCN7ipoqYapKwRdyM1vudKdOLit8yPQ1Or_PoOFZUPqv0w1L__aQwot493SkjLNPD16CI-ufYUmupryQ/http%3A%2F%2Flog.info) to find out what is going wrong but the only thing I’ve found out

```auto
replica.customFields."Customer Request Type".value

```

and

```auto
issue.customFields."Customer Request Type".value  

```

are identical on a system. But the value differs from system A to system B.

Below find all details that may help:

**System A:**

Service Desk version: 4.12.2

Jira version: 8.12.2

Exalate version: 5.0.3-j8

Outgoing rule on system A: replica.customFields.“Customer Request Type” = issue.customFields.“Customer Request Type”

**System B:**

Service Desk version: 4.7.1

Jira version: 8.7.1

Exalate version: 5.0.3-j8

Incoming rule on system B: issue.customFields.“Customer Request Type”.value = replica.customFields.“Customer Request Type”.value

If I use the ids instead in my incoming rule the synchronization works as expected:

```auto
switch(replica.customFields."Customer Request Type".value) {
    case "sdc1/98f72ad7-cd15-401a-9eb7-e0b303345e1d": 
        issue.customFields."Customer Request Type".value = "Request a New Feature"
        break;
    case "sdc1/f585e8bb-b9ae-40da-b1ef-5343d57c0cf8": 
        issue.customFields."Customer Request Type".value = "Improve Functionality"
        break;
}

```

But I don’t want to use such hard coded values as this would mean we need to edit the sync rules when adding new request types in both systems.

Best regards,

Dominik

* * *

#### Comments:

> **Michiel Meurs commented on 13 October 2020**
>
> > Hi Dominik Blum,
> 
> Atlassian has only just enabled this feature and we’re working on a way to improve it. For now, using the ID’s is the way to go. An improvement has been raised for our Dev team.

> **Dominik Blum commented on 14 October 2020**
>
> > Thanks for the information Michiel Meurs

---

<div class="post-metadata">

**Author:** ![xl8bot](https://dub1.discourse-cdn.com/flex018/user_avatar/community.exalate.com/xl8bot/32/324_2.png) [@xl8bot](https://community.exalate.com/u/xl8bot)\
**Post date:** [November 4, 2024, 6:53am UTC](https://community.exalate.com/t/customer-request-type-synchronization-does-not-work/4385/2 "2024-11-04T06:53:06Z")

</div>

_Answer by Hung Nguyen on 12 October 2020_

I assume that you had the same list of values for Customer Request type on both side. Then your switch case should be replaced by this line:

```auto
issue.customFields."Customer Request Type".value = nodeHelper.getOption(issue, "Customer Request Type", replica.customFields."Customer Request Type"?.value?.value)

```

The nodeHelpers.getOption would help you to find a match on your side for the same option value on your side

* * *

#### Comments:

> **Dominik Blum commented on 13 October 2020**
>
> > Hi Hung Nguyen,
> 
> Yes, you are right. I have the same values for the “Customer Request Type” on both sides.
> 
> But there is a problem with your solution. I get always following error:
> 
> ```auto
> Script error for issue SDC1-49. Details: Sync rules include the property that does not exist. Details: No such property: value for class: com.exalate.basic.domain.hubobject.v1.BasicHubVpOrigin. Error line: Script65.groovy:116
> 
> ```
> 
> I assume the value.value is not available for the “Customer Request Type” as following code leads to the error above:
> 
> ```auto
> log.info("Customer Request Type value.value " + replica.customFields."Customer Request Type"?.value?.value) // Does not work
> 
> ```
> 
> But the same code without the second .value works as expected:
> 
> ```auto
> log.info("Customer Request Type value " + replica.customFields."Customer Request Type"?.value) // Works
> 
> ```
> 
> With another custom field with type list your solution works as expected but not with the Jira Service Desk custom field “Customer Request Type”

> **Hung Nguyen commented on 14 October 2020**
>
> > Are you using JIRA Cloud ?

> **Hung Nguyen commented on 14 October 2020**
>
> > Can you change the rule to:
> 
> ```auto
> issue.customFields."Customer Request Type".value = nodeHelper.getOption(issue, "Customer Request Type", replica.customFields."Customer Request Type"?.value)
> 
> ```

> **Dominik Blum commented on 15 October 2020**
>
> > I’m using Jira server.
> 
> Your rule
> 
> ```auto
> issue.customFields."Customer Request Type".value = nodeHelper.getOption(issue, "Customer Request Type", replica.customFields."Customer Request Type"?.value)
> 
> ```
> 
> leads to following error:
> 
> ```auto
> Script error for issue SDC1-51. Details: No signature of method: com.exalate.node.hubobject.v1_3.NodeHelper.getOption() is applicable for argument types: (com.exalate.basic.domain.hubobject.v1.BasicHubIssue, java.lang.String, com.exalate.basic.domain.hubobject.v1.BasicHubVpOrigin) values: [[], Customer Request Type, sdc1/9fa7bdb3-6565-4b26-bec1-dc963f55083f] Possible solutions: getOption(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.String, java.lang.String), getOption(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.Long, java.lang.String), getOptions(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.String, java.util.List), getOptions(com.exalate.api.domain.hubobject.v1_16.IHubIssue, java.lang.Long, java.util.List). Error line: Script104.groovy:31
> 
> ```
> 
> Michiel Meurs mentioned that there is currently not other solution than using the ids.