A different behaviour is observed when using "Request Data" action inside a "List WF" vs "reusable site collection WF".
A LIST WORKFLOW with "Request Data" action is created and published. During publication the "Request Data "action will create a custom Task Content Type in the WF Task List + creates the Edit form (aspx) for this custom task CT inside the WF Task List.
GOOD RESULT: when user opens the "Request Data" Task, the custom Nintex edit form is displayed.
When the "Request Data" action is used inside a Reusable Site Collection WF, and the WF is published.
The custom EDIT form is not available/generated at any time: not created when publishing, not created when assigning the reuseable WF to a list.
BAD RESULT: When end-user opens the task, the default Task edit WF is shown, and NOT the Nintex custom edit form.
I know probably the root cause of this problem: A difference between list WF and site collection WF is that during publishing of the WF with "Request Data"-action:
- The associated Task List is know in case of a List WF, so Nintex will (re)create the custom edit form & custom CT.
- The associated Task List is not know in case of a Site collection WF, so Nintex is not able to (re)create the custom edit form & custom CT.
Only when the Site Collection WF is assigned to a List, then the associated Task WF is know, but the custom form is not generated.
How can it be solved that "Request Data" actions from within a "reusable Sitecollection WF" uses the custom Nintex edit form?
I can think of some workarounds:
- Don't use reusable site collection WF
- Do some manual copying of CT edit form apsx page and powershell scripting...
... but I want to avoid these workarounds.