I'm trying to add a flow with multiple languages using javascript flow scripting sdk. The problem is by default the processing prompt of call data action and call bridge action are set to a system prompt called processing and it does not support the language I want.
I might be able to solve this problem If I'm able to set the processing prompt from the flow scripting sdk itself. I couldn't find anything in the documentation. So is there any way to do that or any other way to solve this problem?
Bridge actions are going away at the end of the year. This is a great time to switch to a data action instead. Visit Topic
Scripting doesn't support setting the processing prompt for a bridge action yet, so the workaround is to upload audio for the processing system prompt for the languages of your flows.
Hi @athuldilip, I wanted to give you a couple updates:
We're in the process of adding audio to additional languages on the processing system prompt. Do you happen to have a list of language tags that you're planning to use? If so, could you let us know what they are?
I agree with @MelissaBailey with her recommendation to look in to using data actions instead of bridge actions but wanted to let you know we just released Architect Scripting 0.3.3 which will provides the ability to set the processing prompt on a Call Bridge Action instance:
it worked in the case of data action, but when I tried it on a bridge action, I found that, unlike "ArchActionCallData", "ArchActionCallBridge" doesn't have a "processingPrompt" member.
Another issue is that I will have to add both data and bridge action call to the flow in order to set the default processing prompt to null or is there a way to create instances of "ArchActionCallData" and "ArchActionCallBridge" without adding it to the flow? (all my flows have a data action so that's not a problem, but none of them uses a bridge action)
I just confirmed that those languages you listed will have audio for the processing prompt once our Architect Data Service deploys to each region. We just got approval on our change management ticket and automatic deployments will happen later. It's region dependent and our service deploys happen off hours.
One thing you can do until the service rolls out and the additional audio is deployed is to manually upload audio for the processing system prompt for those language tags you identified. Granted, that's just supplying audio to make the validation error go away.
With the 0.3.3 release of Architect Scripting, you should now have the processingPrompt available on the Call Bridge Action. Did you update your version of Architect Scripting and are still not seeing it? We just deployed this version a couple hours ago.
I realize that this example code creates an instance of the action but this is running for us without any errors and does set the flow level default to null:
let archBridgeAction = scriptingActionFactory.addActionCallBridge(startupTask, 'call bridge action');
archBridgeAction.processingPrompt.flowLevelDefault.setNoValue();
@jon.vansteen is going to post some code real soon that shows how to do this without having to create an instance of the action where you can set the flow level default and clear out the processing prompt value.
Here is an example of how to set a an action's flow level default setting without having to add an instance of that action. I have provided the code to handle setting the 'ArchActionCallBridge', 'ArchActionCallData', and 'ArchActionCallDataSecure' processingPrompt to no value. archInboundCallFlow is an ArchInboundCallFlow instance, but could be other flow types as well.
archInboundCallFlow.definition.availableActions.forEach(archAction => {
let defaultSettings;
switch(archAction.displayTypeName) {
case 'ArchActionCallBridge':
case 'ArchActionCallData':
case 'ArchActionCallDataSecure':
defaultSettings = archInboundCallFlow.settingsActionDefaults.getDefaultSettingsForActionDefinition(archAction.definition);
defaultSettings.forEach(setting => {
if (setting.propertyName === 'processingPrompt') {
setting.propertyDefaultValue.setNoValue();
}
});
break;
}
});
This feedback is very useful to us and we appreciate it.
At this time, the Architect Scripting package does not supply any Architect Scripting object definition files which can be used by some development environments to provide typeahead suggestions.
FWIW, we're doing some investigation in to exposing a typescript definition file for Architect Scripting types. We can't commit to any deliverables on this at this time but do you know if your development environment can use a typescript definition file to provide typeahead suggestions?
We just released a new version of Architect Scripting ( ver. 0.4.0 ).
Here's the change log entry for it:
0.4.0
Improvements
We made various updates to the Architect Scripting documentation in this release and decided to bump the Architect Scripting version itself to 0.4.0 because the Architect Scripting package itself now contains more metadata about Architect Scripting objects in a TypeScript definition file. Certain development environments can read this metadata and use it to provide a nicer development experience such as providing typeahead suggestions while coding with Architect Scripting objects.
that shows how to do this without having to create an instance of the action where you can set the flow level default and clear out the processing prompt value.