Issue with Dynamically Setting Fieldmap Values in Integration

Hi all,

I'm encountering an issue with dynamically setting a fieldmap value in my integration settings. Here is the situation:

I have a script to set the value of a fieldmap based on whether we are in a production or sandbox environment. While the script executes and changes the value, I do not see this updated value reflected in the flow. Instead, I continue to see the manually entered value that was saved previously when the input was not disabled. Below are screenshots illustrating the issue.


In the flow itself:



I want to dynamically set a setting value to determine if we are in a production or sandbox environment. This is necessary because certain mapping values differ between production and sandbox. By doing this, we can avoid manually changing the values every time we pull from one side of the integration. Here is the script in my settings:

function INIT_SETTINGS (options) {
if (options.resource.sandbox){
options.resource.settingsForm.form.fieldMap.environment.value = "sandbox2"
}else{
options.resource.settingsForm.form.fieldMap.environment.value = "production"
}
return options.resource.settingsForm.form
}

The JSON of the settings:

{
"fieldMap": {
"environment": {
"id": "environment",
"name": "environment",
"type": "text",
"helpText": "Environment of the Celigo Integration, this is needed for example to set the right order source in the flow.",
"defaultDisabled": true
}
},
"layout": {
"fields": [
"environment"
]
}
}

For now I am using a workaround:

I have created a settings text value and kept it empty in both PROD and SB. Then I filled in the PROD with the value "production" and pulled the PROD into SB. After that, I entered a value in SB settings. Now, I am not getting any conflicts. Thanks, @basvanditzhuijzen for this workaround. The only thing here is that when pulling from SB > PROD that the value in PROD changes to sandbox, which then need to be changed manually again.

This workaround is quite tedious, but it seems to be effective for now. If anyone has a more streamlined solution, I would love to hear it!

@nuriensing @basvanditzhuijzen the reason this doesn't work is because the form doesn't resave when you make your pull request. So each time you make a pull, you'd still need to resave the form to get the updated value. The best way to handle this would be to use a preSave script. This isn't a documented script type, but I suppose I'm about to document it here. Essentially, a preSave script can live on just about any resource (integration, flow, import, export, connection) and whenever that resource gets saved, it first goes through this script. It's pretty much the same as a beforeSubmit user event script in NetSuite.

Here is the stub:

/*
* preSave function stub:
*
* The name of the function can be changed to anything you like.
*
* The function will be passed one 'options' argument that has the following fields:
* 'newResource' - the resource being saved.
* 'oldResource' - the resource last saved.
* 'sandbox' - boolean value indicating whether the script is invoked for sandbox.
*
* The function needs to return the newResource object to save.
* Throwing an exception will signal an error.
*/
function preSave (options) {
return options.newResource;
}

You can add it to a resource by adding this snippet to the root:

"preSave": {
"function": "yourScriptFunction",
"_scriptId": "yourScriptId"
}

Script sample for your case:

function preSave(options) {
options.newResource.settings = options.newResource.settings || {};
options.newResource.settings.sandbox = options.sandbox;
return options.newResource;
}