Problem Management

[Manuj Gangwar1]

Just want to know the reason why Two fields  "State" and "Problem state" fields in Problem Table, however both fields having same values. 

[Jaspal Singh · Accepted solution]

Hi Manuj,

As per my knowledge 'State' field is inherited from 'Task' table as 'Problem' table is inherited from Task as well and thus is available readily.

'Problem State' is specific to 'Problem' table that holds state value. Ideally, both fields should have same values at any point in time during its life cycle.

[Aniket Chavan · Accepted solution]

Hello @Manuj Gangwar1 ,

In Problem Management, the existence of both "State" and "Problem State" fields in the "Problem" table can be attributed to the fact that the "Problem" table is an extension of the "Task" table. The "State" field, inherited from the "Task" table, coexists with the specific "Problem State" field introduced in the "Problem" table.

The technical reasoning behind having two seemingly identical fields is likely governed by the need for synchronization. A business rule is likely in place to ensure that the values of both "State" and "Problem State" are consistently the same. This synchronization mechanism ensures data integrity and coherence between the inherited field and the table-specific field.

While both fields are intended to mirror each other, there might be scenarios where reporting or analysis is performed directly on the "State" field. This could be particularly relevant when generating reports that span across multiple tables, and having a shared "State" field facilitates streamlined reporting.

In essence, the dual presence of these fields can be seen as a design choice to maintain compatibility with the parent "Task" table and, at the same time, offer flexibility for reporting purposes. The assurance of synchronization through business rules becomes crucial to prevent any inadvertent inconsistencies in the values of these parallel fields.

Let me know your views on this and Mark ✅Correct if this solves your query and also mark 👍Helpful if you find my response worthy based on the impact.

Thanks,

Aniket

[seanwalters2 · Accepted solution]

Hi Manuj,

This also comes handy in solutioning because if there ever is a critical requirement to introduce a new state only at the problem table - rather than creating that on the task table , you would use problem state field to reduce the impact of the additional state appearing on other tables extended by task. 

Of course any new states should heavily be considered before doing so however just providing a benefit of such design. 

[AndersBGS]

Hi @Manuj Gangwar1 

Problem table is extended from Task. State field comes from Task, and Problem table has Problem State. Technically the values should be the same via a business rule, but in cases were you are reporting on Problems from the Task table, you can report off the State field to get the data.

If my answer has helped with your question, please mark my answer as accepted solution and give a thumb up.

best regards

Anders 

[Manuj Gangwar1]

Just to know the reason behind this for two fields having same values Technically.

[Jaspal Singh · Accepted solution]

Hi Manuj,

As per my knowledge 'State' field is inherited from 'Task' table as 'Problem' table is inherited from Task as well and thus is available readily.

'Problem State' is specific to 'Problem' table that holds state value. Ideally, both fields should have same values at any point in time during its life cycle.

[Aniket Chavan · Accepted solution]

Hello @Manuj Gangwar1 ,

In Problem Management, the existence of both "State" and "Problem State" fields in the "Problem" table can be attributed to the fact that the "Problem" table is an extension of the "Task" table. The "State" field, inherited from the "Task" table, coexists with the specific "Problem State" field introduced in the "Problem" table.

The technical reasoning behind having two seemingly identical fields is likely governed by the need for synchronization. A business rule is likely in place to ensure that the values of both "State" and "Problem State" are consistently the same. This synchronization mechanism ensures data integrity and coherence between the inherited field and the table-specific field.

While both fields are intended to mirror each other, there might be scenarios where reporting or analysis is performed directly on the "State" field. This could be particularly relevant when generating reports that span across multiple tables, and having a shared "State" field facilitates streamlined reporting.

In essence, the dual presence of these fields can be seen as a design choice to maintain compatibility with the parent "Task" table and, at the same time, offer flexibility for reporting purposes. The assurance of synchronization through business rules becomes crucial to prevent any inadvertent inconsistencies in the values of these parallel fields.

Let me know your views on this and Mark ✅Correct if this solves your query and also mark 👍Helpful if you find my response worthy based on the impact.

Thanks,

Aniket