Suppose I have a node that represents a task, or a to-do item:

Node 1: Instructions for building a drivable car

I want to link this node to another node, such as a sub-task of the original node:

Node 2: Instructions for assembling an engine (Sub-task of Node 1)

Now suppose I have another node that is caused by one of my original nodes, but is not a sub-task of it.

Node 3: How to obtain a driver license (required by Node 1)

The entity reference from Nodes 2 to 1 is of type sub-task while the link from 3 to 1 is of type required by (or maybe related to, whatever).

When viewing Node 1, it might be helpful to display a view of referenced nodes, but rather than just showing the nodes, it would be useful to show the relationship type as well:

Items related to "Instructions for building a drivable car":

| Link Type      | Node                                  |
| Parent Task of | Instructions for assembling an engine |
| Requires       | Getting a driver license              |

Applications such as Jira handle this via link types. Is functionality like this available within the Drupal ecosystem? Alternatively, what would be a logical way of implementing such functionality?

2 Answers 2


In Drupal 7, this is possible with the Relation module.

Relations are entities.

So instead of creating entity references to link nodes, when using the Relation module, you create Relation entities, and these Relation entities can contain entity references to two or more entity references to connect them via a "type". In the case of the Relation module, this is an entity type.

Also, because relations are entities, you can add fields to them. And the module provides Views integration and other useful features.

Unfortunately, the port of Relation to Drupal 8 has been abandoned and the maintainers now recommend using the features of core itself-- this is possible, but it's a lot more work than what Relation provided out of the box.

Creating a similar config to Relation module in D8

  1. Make each "type" its own entity type.
  2. Add entity reference fields to each type and set them appropriately.
  3. Customize your Views accordingly.

For many real world scenarios, I'd build your example with multiple fields on the node, one for subtasks, and a second for prerequisites, etc.

Obviously, you can run into trouble with that if you want a truly flexible field with many types of references across many different content types or types of content.

For more robust, "Jira style linking", I would look to create a relationship entity to sit between my content.

Based on your notes, this relationship entity would have three fields: one for Entity A, a second for relationship type, and a third for Entity B.

My relationship type field would reference a Relationship Type taxonomy vocabulary. I'd use the taxonomy term name's field to describe the relationship type from the perspective of Entity A, and add an additional field to describe the relationship type from Entity B's perspective. E.g. Term Name: "Blocks", Alternate Name: "Is Blocked By".

I would also avoid referencing the relationship entity directly from either Entity A or Entity B. I.e. I would not create an entity reference field on Entity A or Entity B to reference the relationship. (The Relationship Entity already knows about both Entity A and Entity B.) Instead I'd look to implement something like what the Redirect module does - it allows you to view all of the redirects on the node screen, but creating a new one opens the redirect form in a new window and does not directly attach the redirect to the node.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.