I wanted to relate to this post as it’s an issue I have been trying to figure out as well, posted about it here:
In this example, I’m not sure I understand how you could use an entity to represent the aggregated “Division Objectives” you mention @Johan_Jonsson. I think about it this way:
You might have, say, 5 teams in 2 divisions.
The OKR will belong to any of the 5 teams.
But no division would have an OKR that belongs just to that division - the OKR is going to be at the team level, and “grouped” with the Division.
In specific terms, like this:
My Department is Marketing. I have two teams in Marketing - Brand Marketing, and Growth. All my tasks, projects, etc. belong to one of those two teams. None belong to just “Marketing.” So in the case of the OKR, we have the same situation. It doesn’t make sense to me to have the Type “Marketing” as a full-on entity.
If the suggested handling of this is to just use the Type “Marketing” as a grouping, and in fact not include any entities directly in it, I think that would work for me. But to clarify, how would I set this up?
- In the relationship creator, I assume I will choose that the parent hierarchy, in this case “Department OKR’s,” have “many” Team OKR’s, and a Team OKR will have “one” Department OKR? Again, this is a bit unintuitive to me as in reality, the Team OKR don’t actually “have” any Department OKR’s. It’s just a grouping, so a different type of relationship. But is this the suggested handling of this?
I can create some levels in my apps for groups using this approach, and just plan that no Entities will live there, just Entity Types. But I’d like to just find out if this is really how you guys intended these “mid-level” hierarchies to work for now.
Would be curious to get your take @mdubakov, in follow-up to the question I just wrote directly on this!
Thanks guys!