The best practice approach to this is to ensure that this data is infact available at time of decision via a data enrichment process. If the data is changing frequently, ensure the changing data is being streamed into the system and the record is always up to date when used in the decision process. 
 

if this technique is not viable (you should strongly assess why it’s not and strive to move to this approach) then you should consider a few other questions.
 

Is this purely for inbound cases that you need this data? If so, you can update the single case customer data flow to pull in this extra data via a transform that calls your connector. This approach adds overhead to the data processing pipeline and is the reason it’s not considered best practice, but will work. Another similar approach is to pass the data into the call to the container as contextual data. The container API allows you to pass in name-value pairs of data that you can then reference in your strategy. This approach is particularly good if you already had the data in context before the call to the container. 
 

Note that both these approaches make your strategy inbound specific and therefore is another reason it’s not considered best practice, as you really don’t want to call out to a service, customer by customer for outbound cases, where bulk processing at scale is critical. 
 

Hope this helps and good luck. 

Hi Saleem,

thanks a lot for your answer, I like to read your posts, they always carry lot of vital information.

I think that I understand how this is not the best practice, however probably our only option now. As I am quite new with Pega Marketing module I somehow overlooked the option of adding data transform to the Data Flow. It is purely for inbound cases so this should be the solution.

Thanks a lot and have a great day :)

Martin

One small, but important update to this. 

There is no support for dynamic parameters for the Data Transform shape in Data Flow. Only static value is viable for now.