@rnikkoprado

This is an excellent question. I would think about this in terms of the upcoming release of our next version (V22). You want whatever option you choose to make sense in both versions. You will still require references between projects in 19.1 however (at least at the controller level) for those projects to get included in the build.

In V22, we no longer have separate projects and instead group everything via folder or adapter (which are now called Applications). Each Application can be built using Application Methods which allow you to essential package an application with all its functionality making it effectively behave like a project.

The Interaction Framework (IF) is a great tool for having communications between projects without needing direct references between them. For example, if you have a Controller, and beneath it, two children, the children don’t have to reference each other if you needed to trigger automations across projects in the other child project. Its main use however is for storing customer data particularly when you need to switch between customers. Imagine an attended automation where you collect notes to apply to a caller’s account. You might be collecting these when your customer gets disconnected. You might then get another customer before you have a chance to notate the first customer’s account. You’ll need to retain all that information and switch back to it later. Another use case for the IF is for when you need to cancel an automation. For example, a customer call triggers an automation to acquire some of their account information for verification purposes. This automation takes 30 seconds or so. During the automation, the caller hangs-up and a new caller requires the same information from their account. You’d want to cancel the first automation and then re-run it against the new customer’s account as quickly as possible.

In 19.1, it makes sense to use separate projects for discrete functionality. In V22, these projects will be treated as folders.

My suggestion is to use the IF where it makes sense and specifically architect your solutions around it. For example, when build unattended automations, you cannot really utilize the IF assuming you are using Pega Robot Manager to trigger your automations. This is because activities are queued meaning you cannot have an activity start another activity and continue once it is finished since they occupy the same queue. This is best thought of like a checkout lane at a grocery store. I can’t be checking out and then insert someone into the same line and let them checkout while I am also checking out and then finish when they finish, because only one of us can go at a time.