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. 

[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. 

[Dr Atul G- LNG · Accepted solution]

Hi @Manuj Gangwar1 

This is something i learn in my ITSM training. If you see Incident also has 2 state field, one which is coming from Task and one created on specific table it self. There is BR in backend which run and sync both the fields. The purpose may be use OOTB or if you want to do modifictaion use Table specific field.