unofficially, variables are considered depreciated. It is not always easy to apply the concepts for variables to parameters. If teams would create variables in their own process groups, this would have 0 influence on other teams and other process groups. Implicitly, the variable only lives at its local process group plus its subprocess groups. With parameter context, I have reservations about giving everyone the freedom to create such contexts. Many users are not aware that they are creating something global that needs to be explicitly managed.
I have central questions:
1. Should parameter contexts be controlled only by the admin to prevent uncontrolled filling?
2. Copying a process group with context does not cause the context to be copied. This is currently difficult to explain to users.
3. Assuming users are allowed to create contexts, how do I separate them efficiently? Example rule: All contexts created within the Team A process group should be visible and accessible only for Team A.
4. How granular or comprehensive must a context be? I have experimented myself and have come to the conclusion that the more granular the context, the more difficult it is to use again. Global parameter contexts on e.g. project level, system level or team level are much more conclusive. Unfortunately, contexts can neither be inherited nor can they be combined in a process group.
Parameters are still quite new and powerful. What experiences have you made so far? Do you manage without variables in your use cases?