Bridge: Passing parameters to child workflow

Hi,

I have setup a solution to get data from Smartsheet Resource Management and send it to Smartsheet. I have 4 workflows setup in a parent child relationship to accomplish this.

"SS - Update Budget Totals" > "RM - Get Budget Totals" > "SS - Add Totals Rows" > "SS - Add Rows"

a) "SS - Update Budget Totals" calls "RM - Get Budget Totals"

Parameters passed: sheet_id and url of smartsheet

b) "RM - Get Budget Totals" calls "SS - Add Totals Rows"

Parameters passed: sheet_id and RM_data

c) "SS - Add Totals Rows" calls "SS - Add Rows"

Parameters passed: sheet_id and Re-constructed RM_data for HTTP Call into Smartsheet


My problem is that everything was working fine after making and testing the solution on 8th of Sep. Today, I accessed the solution to change the API key and I found that in step b) when "SS - Add Totals Rows" is called, instead of receiving the sheet_id and RM_data as parameters, its receiving sheet_id and url instead, which was passed to its parent as parameters instead!!!


@Genevieve P. (with your knowledge and experience of the Smartsheet ecosystem), can you please shed some light into why this could be happening? This happened to me a month ago, and then I had to re-create a new workspace and re-create the whole solution from scratch. It is very frustrating.


Regards,

AK

Answers

  • Genevieve P.
    Genevieve P. Employee Admin

    Hey @akhalid

    Apologies for the delay!

    I'm not quite sure I understand where the disconnect happens... do you mean that the Parent Information passed through the trigger is bringing through the URL instead of an ID?

    Can you show screen captures of the Child Workflow Module which shows the values being passed across under the "Child Entity Values" header, and a screen capture of the Run Log, highlighting the same values?

    Here's more information on Parent / Child Workflows:

    Cheers,

    Genevieve

  • akhalid
    akhalid ✭✭✭

    Hi @Genevieve P. ,

    Thank you for your response.

    Yes, that is correct, trigger information is bringing in the URL instead. As simple as the parent / child workflows are and the way parameters are passed down the chain, what is happening IS mindboggling.

    Since posting the above problem, I created simplified Test workflows to reduce the number of variables. In my simplest test workflows, the parent-child-grandchild relationship is as follows:

    Test_L0 > Test_L1 > Test_L2

    Test Results:


    Workflow Screenshots:

    Test_L0 calls Test_L1 with parameter, parent is l0. Test_L0 is triggered manually.








    Test_L1 calls Test_L2 with parameter, parent is l1. Test_L1 is triggered by Test_L0.

    Test_L1 receives the CORRECT trigger entities parent is l0.


    Test_L2 receives the INCORRECT trigger entities parent is l0.

    It SHOULD HAVE received parent is l1.









    Regards,

    AK

  • Genevieve P.
    Genevieve P. Employee Admin

    Hey @akhalid

    Thank you for following up and providing screen captures!

    I'm struggling to reproduce what you're experiencing - I ran the exact same test as you, but my third workflow output data from my 2nd workflow under "Entities" (not the 1st workflow's data, as you're seeing).

    I notice you haven't added any value in the "Number of Runs" part of the module. Can you test adding that in?

    When I add in a number 1, my third workflow then show both the 1st and 2nd workflow values that are being passed through.

    I'm curious to see if this helps surface the correct data, and if perhaps there was something to do with the same key name being used that confused the module.

    Thanks!

    Genevieve

  • akhalid
    akhalid ✭✭✭

    Hi @Genevieve P. ,

    I tested my workflow setup before making the suggested change. To my surprise, the problem seems to have fixed itself! I can't re-produce the problem anymore.

    I'll keep an eye on it and see if it happens again. Then I'll apply your suggested change and check if that instantly fixes it.

    Regards,

    AK

  • Genevieve P.
    Genevieve P. Employee Admin

    Hey @akhalid

    Thanks for following up! Please do let me know if it happens again.

  • akhalid
    akhalid ✭✭✭

    Hi @Genevieve P. ,

    I encountered the problem again today and applied the fix as you suggested. It worked like a charm! :-)

    You are certainly a star of the Smartsheet world with a solution for everything.

    Thank you!

    Regards,

    AK

  • Genevieve P.
    Genevieve P. Employee Admin

    Hey @akhalid

    Thanks for letting me know that it happened again, we're looking into it. In the meantime, I'm glad to hear that adding a value in the Number of Runs field helped!

    Cheers,

    Genevieve

  • akhalid
    akhalid ✭✭✭

    Hi @Genevieve P. ,

    I had written to support about this issue and I finally got a resolution:

    My Engineering team has followed up with me to confirm that this behavior was related to a bug. After their investigation, they've made a fix and have since been unable to reproduce it.

    My Engineering team had been able to reproduce it consistently in their test environment but now they are no longer able to with the fix in place. Can you confirm if your workflows have experienced the behavior in any of their runs after Monday the 6th?

    I will close out this case for now but if you experience the issue again, please reply back and it will reopen the case so that we can assist you further.

    So apparently the fix was put in place on 6th of Nov. Lucky you had provided a work-around, otherwise I would have to wait until now (and make our clients wait too)!

    Regards,

    AK

  • Genevieve P.
    Genevieve P. Employee Admin

    Thanks for following-up!

    I'm glad that the suggested workaround helped you, and doubly glad that the resolution is in place for any future workflows. 🙂