Incident task table vs Domain Separated Instances

[PiotrI]

Dear Community,

I got a rather straight forward question. Having in mind the data domain separated instance, are there any issues with incident_task table usage in such an environment ? I mean I got it that all incidents opened in a certain domain are going to reside in that domain and it's matter of the Domain Design to address the visibility of these tickets, but are there any other constraints that would call against using incident_task table and use task table instead?

[lastreaction122]

@PiotrI wrote:

Dear Community,

I got a rather straight forward question. Having in mind the data domain separated instance, are there any issues with incident_task table usage in such an environment ? I mean I got it that all incidents opened in a certain domain are going to reside in that domain and it's matter of the Domain Design to address the visibility of these tickets, but are there any other constraints that would call against using incident_task table and use task table instead?

---

Hey Piotrl!

It comes with certain considerations that may influence its suitability depending on your specific requirements. While incidents and their related tasks will generally adhere to the domain they were created in, ensuring proper visibility across domains is critical.

The incident_task table is purpose-built for incident management, and as such, may have more restrictive access rules in a domain-separated environment compared to the broader task table. If your tasks need to extend beyond incidents or require collaboration across multiple domains, using the more general task table might offer better flexibility and reporting consistency.

Additionally, domain inheritance rules need to be managed carefully to avoid unintended restrictions when using the incident_task table. Therefore, if there is a need for cross-domain functionality or more generalized task handling, using the task table might be preferable to avoid potential limitations.

[PiotrI]

Hey!

That's what I thought. I wanted to crosscheck if there are any constraints to be honest. I'm not a huge fan of domain separation at all, got to check the exact requirements first 🙂

Thanks for the answer !

[EstateAgenI]

In a data-domain separated instance, the incident_task table works fine as long as your domain design handles visibility correctly. There aren’t inherent technical constraints preventing its use, but keep in mind: incident_task is tightly linked to incidents, so it inherits domain restrictions and lifecycle behavior from the parent incident. If you need tasks that exist independently of incidents or span multiple domains, the generic task table might be more flexible.

[EstateAgenI]

In a data-domain separated instance, the incident_task table works fine as long as your domain design handles visibility correctly. There aren’t inherent technical constraints preventing its use, but keep in mind: incident_task is tightly linked to incidents, so it inherits domain restrictions and lifecycle behavior from the parent incident.