"Activate new portfolios associated with service automatically?" has just 2 options (Yes and No), and it doesn't just control what happens when new portfolios are added to the collection; it also controls what happens when portfolios are deleted from the collection. I think there are probably additional use cases besides these as well.

If "Activate new portfolios associated with service automatically?" is set to "Yes":

New portfolios added to CZ collection are automatically activated in IZ
Portfolios deleted from CZ collection are totally deleted from IZ

If "Activate new portfolios associated with service automatically?" is set to "No":
New portfolios added to CZ collection are not automatically activated in IZ
Portfolios deleted from CZ collection become local and inactive in IZ and get a special status on the CZ updates task list, giving us a chance to check and either re-activate or activate in a different collection (say, if the portfolio moved to a different provider).

We find these 2 options aren't granular enough for an important use case: There are many cases where we subscribe to a package that consists of all the titles offered by the publisher. We have perpetual access to the content published during the years we subscribe, and when the publisher issues a new title, it automatically joins our package. After entering our perpetual access data into our portfolios in these collections, we'd like to make sure they're not deleted by any CZ processes (as they're perpetual, so we want them to stay in our IZs!). However, we still want to make sure that when the provider adds a new title to the CZ collection, it is automatically added to our IZ.

So, we want the "Yes" behavior for new portfolios but the "No" behavior for deleted portfolios, but there's no way to do that in Alma at present. An improved setup would have separate settings for new portfolios and deleted portfolios that each library could control, as shown in the attached mockup.

As you can see, I have mocked up a new field "Delete portfolios removed from service automatically?" with the options "No, make local and inactive," and "Yes, delete completely." With this improvement, "Activate new portfolios with service automatically?" would just control the behavior of new portfolios, and the new "Delete portfolios removed from service automatically?" field would control the behavior of deleted portfolios.

I shared this suggestion with colleagues in the CZMG, and I received support for the perpetual access use case as well as a suggestion of another use case: if a library has attached CZ portfolios to local records, they may wish to be able to control the additions and deletions behaviors separately so they are able to more closely control the portfolios attached to the local records.