In almost all applications, we design multiple case types that share a significant number of common attributes. From an architectural perspective, the cleanest and most maintainable approach is to define these shared attributes at the application (work-pool) level and let individual case types inherit them through the class hierarchy.
However, Blueprint currently only allows properties to be created at the case-type level, not at the application level. This forces teams to clean up the properties on case types to remove this redundancy before proceeding further.
As applications evolve, teams often need to manually re-save or relocate these shared properties into the work-pool class later ; an avoidable step that would not be needed if Blueprint supported defining shared properties at the application level from the start.
Given this, would Pega consider enhancing Blueprint to allow property creation at the work-pool / application level, so shared attributes can be defined once and reused cleanly across case types?
Such an enhancement would align Blueprint with real enterprise data-modelling practices, streamline Constellation development, and significantly improve long-term maintainability.
@MidhunKrish I recognise this challenge but just being able to define data model rules on application level might be a too tight feature. The challenge I think begins in App Studio. In there you currently have no means to define on what level your rules end up. That not only holds for data model rules like properties, but also for flow rules for example. If you want to share a rule with multiple case types, you would normally define the rule on a shared work class. This can be any level in the class structure that those case types share. If you would configure this now in Dev Studio, as soon as you open such a flow, which can only be done in the context of a specific case type, in App Studio and save it, a copy of the rule will be created in the work class of the case type selected. And then reuse ends unless you fix it in Dev Studio again.
So, I think the capability to define or at least modify rules on a higher level than a specific case type should be added to App Studio first. Following that, Blueprint could adopt the possibility to define data model rules and others on other levels than just the case type at hand. And ideally, Blueprint already knows the existing structure and assets available and incorporates that into the Blueprint created. See also this discussion: Should Pega Blueprint support an enterprise asset registry for reuse?
So in short, I agree that being able to leverage inheritance on the Work levels would really be a valuable addition, both in App Studio and Blueprint.
@NielsHeinis Exactly! My thought was that Blueprint has much faster upgrade cycles, so adding application-level property creation there would allow Pega to deliver this capability much sooner. Blueprint already generates the technical artefacts automatically, so enabling this would mean a cleaner data model right at start, without waiting for deeper platform changes. And yes , I agree that this should also be supported in App Studio.
I appreciate the value you’re adding to these discussions and your focus on enhancements that improve both technical capability and business value.
Here are a few related conversations I’ve been part of and feel free to take a look and add anything you think could strengthen them further.Some of the earlier enhancement requests have already been addressed, which shows that Pega genuinely leans in and listens when these gaps are raised
You can create data objects to hold any commonly used fields. Blueprint’s support for embedded data and the ability to choose specific fields from an embedded structure should help achieve the same level of reusability. If you’re not concerned with reusability, you can quickly copy Case Types by cloning them. In the future, we’ll add more features to Blueprint import to allow you to place Fields and other rules in different classes, which should help avoid rule deletion and creation.
We’ve also discussed adding an organisation library to Blueprint, where you can define COE-level assets. We’ll consider implementing this feature in the future.
@SumanKumar Thanks for the response! I’m with you that the embedded-data approach is an acceptable workaround (and easily the quickest short-term fix) to avoid thinking about moving shared properties to the work-pool level. But it still introduces two practical issues:
the same property paths end up being cloned across all case types to embed the data type that contains the common attributes
and reporting from the work-pool class remains messy because those properties don’t actually exist at that ancestor level
So while the modelling works, the operational impact on cross-case reporting and long-term maintainability is still there.
Great to know that Pega will consider implementing this in one of the future Blueprint releases!