Distinguishing between assignments with Split for Each shape

Hello,

Can anyone provide guidance on how to distinguish between the assignments when using a Split for Each shape?

For example, if there are multiple steps that say ‘Complete Deliverable,’ I may want to provide more context in the label so that I know which deliverable needs to be completed.

Since we can’t override the section, how can we edit that?

Configuring the parameter with the prefix/suffix and the assignment name. I hope this works in Constellation

Unfortunately, this does not directly work here.

The assignments component is getting the task name from pxFlow().pyLastFlowStepLabel by default. If this property is empty, only then it is looking into the pxTaskLabel property that is saved in Assignment. (Step 7.1 and 7.8 in pzSetAssignmentsList )

So, for this to work, first we have to write a data transform on the pre connector to set a parameter.

Next, extend NewDefaults activity of Assign- class and set value of that parameter to .pxTaskLabel

And most importantly for all the above set-up to work, the step label needs to be empty. If we give a value here, system does not consider our logic and simply uses step label.

I don’t think removing the step name in a flow is a best practice. But, to achieve this requirement, this seems to be the way right now.

It would be great if this component also uses pxTaskLabel from assignment directly to show the Task Name (similar to OOTB worklist widgets) instead of relying on pxFlow and showing the step name which we cannot customize. @MarcCheong

Agreed! Keeping the flow name as blank is not a good practice. However, there is no when condition in the NewDefaults activity. Could you please confirm if NewDefaults will be triggered in Constellation during the case workflow?

The when condition is not in NewDefaults, it is in pzSetAssignmentsList which runs when we launch the case and the screen is loaded. And yeah NewDefaults is being triggered in Constellation.

I am not seeing the assignment name blocking NewDefaults. Infinity '25.1.2

With a split join this approach works without removing assignment name.

Example

I named each assignment with the “Prerequisite Name” from the captured data in my embedded list.

Configuration

  1. To on the flow executed from the split join
    1. I created a parameter
    2. I used a set to set the parameter using case data level details
  2. In the NewDefaults activity
    1. I created parameter
    2. I set this for Assignment Name (.pxTaskLabel)

@morak let us know if that works for you :slight_smile:

It works in v25. I tried in v26 and it doesn’t and the reason is obvious from the code.

In 25: Preference given to pxTaskLabel from Assign-.

In 26, preference given to local.TaskLabel which is from pxFlow().

Yes, thank you all for the inputs!

I just tried in v26 as well, and I had the same observation that it’s not working.

Is there another workaround for v26?

I would leave the assignment empty - it is not great from a development standards perspective but the priority should be the user experience :slight_smile:

We should also raise a Pega Support ticket here. It may be an unintended '26 change.

I tried to leave the assignment empty, but that’s not working for me either. The label just shows up as empty on the assignment in that case.

We can write a custom activity to open the assignments and update the pxTaskLabel with more meaningful information, but that’s not the best approach.

After leaving the label empty, you can use steps in mine or @MarcCheong 's first reply. That should work.

I still haven’t been able to get it to work, unfortunately.
Can you see anything I might be missing from the below configuration?

Thank you!

Added parameter to split join flow:

Set property:

Assignment name empty:

Saved NewDefaults activity into my ruleset and set property:

Assignment name shows up empty:

@morak The // in your step 1 actually makes Pega skipp this entire step - that is why it is not executing. Easy miss, especially when you copied it from OOTB (where it is //)

@MarcCheong ah yes, thank you for pointing out my user error! It’s working now. :slight_smile:

I appreciate all of the help!