Skip to Main Content
Nintex Ideas

đź‘‹ Use this site to provide feedback and ideas for all Nintex Products. See our post on Nintex Community "Welcome to Nintex Ideas" for more details on Nintex Ideas, how an idea is handled by our product teams and more!


If you have questions about Nintex Ideas, please contact ideas@nintex.com

If you require support, please visit Nintex Customer Central

If you have a sales inquiry, please contact sales@nintex.com

Status Not Planned
Categories Runtime
Created by Guest
Created on Jun 27, 2017

Capture of Request Content in workflow variable

External start workflow required the "Request content (parameters)" to be provided in the body of the REST call, capturing the "Request content" into a workflow variable, allows capture of additional data that are not defined as Start Variable(s) of the workflow. This capability supports External Start workflow in Nintex Workflow Cloud to be used as a "Callback URL" end point. This end point with the "Request Content" captured, supports the parsing of returned data and actions to be taken against the returned data.

External Start workflow if capable of capturing Request Content is important as it supports action to be taken on the callback request such as writing the returned value(s) to Sharepoint online list item, etc.

Please feel free to discuss the concept and usage behind.
  • ADMIN RESPONSE
    Sep 7, 2022
    Closing out the suggestion due to low votes.
  • Attach files
  • Guest
    Reply
    |
    Sep 7, 2022
    Hi KK,

    Our recently released and revised 'Call a workflow' action in Nintex Workflow Cloud also automates the configuration of these External start features you have mentioned when using external start to call a workflow from another workflow. To explain further, when designing what will be a child (or called) workflow, the designer can in addition to determining start variables, can now also specify what variables should be considered 'output' variables of the workflow.

    When configuring the 'Call a workflow' action in the parent (or calling) workflow, the designer can choose which External start workflow from within the tenancy the action should call. Once selected, the action configuration panel renders controls for configuring the input and output variables that should be sent to and received from the called workflow.

    I hope you find this information useful.

    Regards,
    David
  • Guest
    Reply
    |
    Sep 7, 2022
    Hi mate,

    The concept/idea presented here is very different and with different opbjective than the External Start with "Output" variables. Let me try to provide more details here:

    We can now call/trigger Nintex Workflow Cloud's External Start workflow today with the following payload.

    {
    "startData":
    {
    "se_firstname_11": "John",
    "se_secondname_21": "Smith",
    },
    "options":
    {
    "callbackUrl": "https://callbackurl.com"
    }
    }

    This is great as the workflow once completed will be able to make a callback to the "callbackurl".

    Now, as the External Start workflow only understand the payload of above (i.e. with "startData"), we can only parse the payload to take passed parameters/values into the workflow's variable(s).

    If a External Start workflow besides parsing the mentioned payload, it also take the entire payload/request content into a variable. We can now make the External Start as a service endpoint for "call back" purpose. Meaning we can now parse the return of another workflow of the following content:

    {"returnData":
    {
    "c_status":"Review",
    "se_firstname_11":"John",
    "se_secondname_21":"Smith"
    },
    "workflow":{"id":"a58a5b90-eda6-41af-8acb-00fe299c68a6",
    "name":"",
    "publishedId":"3cace836-0323-4f79-b56f-5480bf79aab7"
    }
    }

    This External Start workflow is now handling the return/ reponse of the first External Start workflow, and process the returns the way we want it. Such as feeding that responded data to Sharepoint Online list item, etc.

    Support of "callbackurl" in the return is good, but it is not easy to implement, as we need to create endpoint to receive the response from the called "External Start" workflow. Now, with this idea, we can simple turn another "External Start" workflow as the endpoint for the callback.

    Hope that clarifies.