We have configured a watched folder in AEM forms and it's ingesting the file successfully. However, in the advanced configuration, we have some customer properties being configured however, the workflow is not setting them. Are we doing something wrong?
Basically, we have a string called "inputType" and we set it to the string "file".
In the workflow, we create a string variable called "inputType" and it's value is undefined when it gets kicked off.
Here is a reference to the documentation. We have verified that it is set using CRXDE too.
A specific set of properties can be set as custom properties , and I see that you've already set the property to "string."
Also, these properties need to be prefixed with workflow.var.* or param.* depending on the use case and should have a default value (if you see an undefined value). You can enable debug logging to check the key-value pairs set once invoked.
 - https://experienceleague.adobe.com/docs/experience-manager-65/forms/publish-process-aem-forms/watche...
This one's interesting..
- I set a custom parameter 'var1' on the watched folder config node:
- I then triggered a workflow by dropping a file in the input folder of the watdched folder. If you have a look at the workflow instance in CRXDE, the 'payload' node has path to the payload:
- If you navigate to that payload path, it takes you to the payload node where you'll find the custom watched folder properties, under node 'var':
This means that the custom properties are definitely part of the workflow payload, however I don't know if we can use this custom property in the workflow as an author, without custom code.
We have configured the Custom property in the Advanced Section of the Watched Folder config.
And, it's confirmed in CRXDE
We have a variable in our target Workflow:
When I drop a file "data.xml" into the watched folder, the variable is not set. And, the "var" node in CRXDE is empty.
I tried manually setting "workflow.var.inputType2" in CRXDE. I created a workflow variable inputType2 and it is still undefined. However, it has appeared in the "var" node of the instance just like @Nikhil_Verma shows in that example.
Clearly there seems to be a misunderstanding of how it works or a bug, right?