Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

This post is a little extension of the lunch-walk mentioned last week. A second topic was re-discussed! A discussion about inheritance and whether it’s good or bad. Well, I can tell you it’s not always smart to do and this post shows other (building block related) topics where you might want to change course of the ship.

Let’s dive into it and skip all the introduction talks…Sometimes it’s simply better to have a closer look with concrete examples.

---

Let get right into it…

Boot up your favorite platform and login to your relevant workspace and project. The first thing we do is create a new ‘Case’ entity with just a simple case_name property. Generate all the default BBs and make it appropriate with your own naming convention.

Next, we’ll create a new subtype of this ‘Case’ with the name case_special:

The first thing you’ll notice is that there is an inheritance of BBs except for the ‘List’ BB! So, for this entity we’ll create a new one with the name lst_all_cases_special that exposes the inherited case_name in runtime. Hereby a quick compare shot:

You can do a publication already and try it in runtime, but it’s not required to continue.

Our basic structure is ready to start adding new BBs to the parent ‘Case’ entity and have a verification/conclusion what is the outcome on the child ‘Case special’ entity. To keep it structured I’ll put the data in a table for easy consumption:

Building block	Inherits?	Is replaceable?	Available on subtype?	Notes
Property	✅	❌	✅
Relationship	✅	❌	✅	It even inherits a to_one_case_special relation!
Action bar	✅	✅	✅
Form	✅	✅	✅
Layout	✅	✅	✅
List	❌	N/A	✅	You need to explicitly add this BB to the subtype as well!
Title	✅	✅	✅
Activity flow	✅	✅	❌	There is NO option on the subtype itself to add this BB!
Assignee	✅	✅	✅
Deadline	✅	✅	✅
Dynamic workflow	✅	❌	❌	There is NO option on the subtype itself to add this BB!
Lifecycle	✅	✅	✅
Rule	✅	✅	✅
Rule category	✅	❌	✅
Security	✅	✅	✅
Sharing	✅	✅	❌	There is NO option on the subtype itself to add this BB!
Tracking	✅	✅	✅
Business workspace	❌	N/A	✅	You need to explicitly add this BB to the subtype as well!
Content	✅	✅	✅
Discussion	✅	❌	✅
Email	✅	❌	✅
Email template	✅	✅	✅
File	✅	✅	✅
History	✅	✅	✅
Mobile app	❌	N/A	✅	You need to explicitly add this BB to the subtype as well!
Notification	✅	✅	✅
Web service	❌	N/A	✅	You need to explicitly add this BB to the subtype as well!

Also, interesting to see is that I have the case_special screen open all the time, and it gets a refresh on the fly! I thought this was different in the past, but not sure!?

Well, make your conclusion; Inheritance isn’t always what it looks like. You’re also not always in control on what you inherit! AND you’re also not in control when you don’t need the inherited part at all for your specialized solution. This last sentence is sometimes forgotten in projects; Inheritance should help you, not work against you.

---

There is nothing more to add; It’s a “DONE” from my side where you see what inheritance can(not) do for you. Use it wisely as using it wrongly will inject functionality into your specialized project that is even not possible to disable at all! The other side of the medal is that a subtype depends on its parent; So, when you need a ‘Dynamic workflow’ functionality for example, you must add the BB on the parent entity. This can cause conflicts when the parent-entity-project-team doesn’t agree on this! Enough to think about this weekend; I see you next week…Cheers! 🍻

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?