The custom-activity-deskapi-node example application helpfully demonstrates how two Custom Activites can be used to pass outArguments from one 'create-case' Custom Activity:

"outArguments": [
   { "caseID":"number" }

To another 'update-case' Custom Activity in the Interaction as an inArgument:

    "caseID":"{{Interaction.__your-activity-customer-key__.caseID}}" }

This works well and I want to achieve something similar, but instead of using two Custom Activities, I would like to just use one.

Continuing with the scenario provided in this example application, let's say you want to create a case using the selected caseId value when a Contact reaches the Custom Activity in an Interaction. In order to achieve this, the config.json file would need to look something like this:

"arguments": {
    "execute": {       
            { "firstName":"{{Contact.Attribute.__your-de-name__.FirstName}}"},
            { "lastName":"{{Contact.Attribute.__your-de-name__.LastName}}"},
            { "emailAddress": "{{Contact.Default.Email}}"},
            { "caseID":"{{Interaction.__your-activity-customer-key__.caseID}}" }
        "outArguments": [
            { "caseID":"number" }
        "url": "https://__insert_your_custom_activity_endpoint__/ixn/activities/create-case/execute/",
        "verb": "POST",
        "body": "",
        "header": "",
        "format": "json",
        "useJwt": false,
        "timeout": 10000

Is this actually possible or supported? That is, can you define an outArgument in a Custom Activity, then use that value as an inArgument (using the Interaction context) within the same Activity?


I'm not sure I understand fully what you want to do with just one activity. But to answer your question, no, you can't define an outArg to be used as an inArg within the same activity.

inArgs are for data coming into the custom activity. Journey Builder will POST to your execute endpoint with a payload that includes inArguments. Your activity can use those inArgs for whatever processing your activity needs to do.

outArgs are data that you will include in your response payload for that activities' execute method:

res.send( 200, {"caseID": data.id} ); //return the new CaseID

However, given the example config you gave, there would need to be more than one activity. The inArg caseID specifies an activity further up the stream: Interaction.REST-1.caseID. Using it this way implies the current activity (your example) is downstream. The outArg caseID implies that this activity, call it REST-2, outputs a caseID of its own. Even further downstream another activity can use either of these values:


            { "caseID-1":"{{Interaction.REST-1.caseID}}" },
            { "caseID-2":"{{Interaction.REST-2.caseID}}" }

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.