Service Request (sc_request) table for

Community Alums
Not applicable

Hi All,

I need advice on utilizing Service Request table both for catalog orders as well as requests handling. Design wise, i want to create   a record producer and catalog items on Service Request and handle them separately. Just like incident table to handle requests (without RITMS) only REQs.   Any suggestions or best practices?

5 REPLIES 5

HI Karthik,



Personally, I never really understood why we have task.state and incident.incident_state, problem.problem_state, etc. I've heard theories, but never really used them nor found a use. If you don't need duplicate fields, then I wouldn't involve the extra complexity of a second field and keeping it in sync if there's no real value.