You are viewing limited content. For full access, please sign in.

Question

Question

Setting up Input Parameters

asked on April 3, 2019

I have 2 Workflows:

- Part Development Creation (Workflow A)

- Part Development Processing (Workflow B)

 

Workflow A is initiated by a Form and then invokes Workflow B. I need to pass these Forms variables from Workflow A to Workflow B.

I have 2 Input Parameters set up in Workflow B for BP Instance ID and Submission ID:

 

In Workflow A I have assigned the Input Parameters the BP Instance ID token and Submission ID token (see screenshot 1 attached).

In Workflow B, I added a Retrieve Forms Variables activity but in the advanced properties I do not have the option to assign the Input Parameters from the other workflow to point it to that Instance or Submission ID (see screenshot 2 attached).

 

I have read other Answers post but they aren't exactly clear on which Workflow they are configuring these under. Am I missing something small or am I doing it backwards?

 

 

 

Screenshot 1.PNG
Screenshot 2.PNG
Screenshot 1.PNG (80.03 KB)
Screenshot 2.PNG (30.37 KB)
0 0

Replies

replied on April 3, 2019

Workflow B shouldn't use the activity to retrieve business process variables, that's only for grabbing variables from a Forms process. You should use retrieve business process variables in workflow A to grab them from forms, then pass the values from WF A to WF B. 

0 0
replied on April 3, 2019

Then how would I use the variables from the Form in Workflow B? I would need to pass each Form variable separately as individual Input Parameters?

0 0
replied on April 3, 2019

For my solution, you would have input parameters for WF B and then use the tokens from WF A to send values over to WF B. To be clear, don't send the instance ID and submission ID, send over the actual values from the process you wish to use. 

The pros for this solution would be the values you grabbed from the Forms process would be the same as from WF A. If you looked up the values again in WF B, they may have changed since WF A got them. This also will have better performance since you wouldn't have to look up the values from Forms twice.

The con would be a little extra maintenance. If you added a new field to your form, you would have to add an input parameter in WF B, then update WF A to grab the new value and pass that into WF B as well. I think this solution would still give you the best data integrity and performance. 

BUT

If you want to go with your solution and look up values in WF B as well, if you go to the token dialog, those tokens should still be there. You can pass in the submission ID and instance ID and look up the values from the Forms process. These values may have been updated since WF A grabbed them, and the performance may not be as good. 

1 0
replied on April 3, 2019

So this is what I was trying earlier with no luck. Sending screenshots to make sure I didn't miss anything.

In Workflow A, I assigned my Customer token from Forms into the input parameter (see screenshot "Workflow A - Invoke Workflow") I have attached a screenshot of my input parameter on WF B also

Then in my Assign Field Values activity, I am assigning the token that is passed through from WF A but it does not assign anything. If I track tokens, those tokens are blank as if nothing was ever passed over from WF A.

Did I miss anything?

0 0
replied on April 3, 2019
0 0
replied on April 3, 2019

Tokens are filtered by type in an attempt to make the list shorter and more useful to the user. If you open the Token Dialog you should have access to the full token list, including the input parameters.

1 0
replied on April 4, 2019

I am not sure if this may be a bug in 10.3.1 but I am unable to get any tokens to pass through using Input Parameters for both methods mentioned above. I attempted to create my own token on WF A and attempted to pass that through with no luck as well. I will try this in our 10.4 sandbox server and see if I make any progress. Thanks for the help.

0 0
replied on April 4, 2019

Hi all - I created a simple test process in our 10.4 sandbox server and all worked as expected so then I created a similar basic process in our clients 10.3.1 server and that worked as well. So it appears it must be something in my specific process used above so I will investigate further and see if I can determine what is happening.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.