why notification, business rules, etc. are not inherited from the parent table?

[jzhou]

Hi,

  I am new to the developer group and I extended the incident table,, and assumed the notification and business rules, etc would be inherited to the child table. But it seems not, not sure if I miss any thing here? For example, there is a notification to notify called "Incident opened for me", if submit a new case from incident table, it fires, but if I submit a new case from the child table with the same condition, it did not fire.

  Could any one help out or point some related documentations of what and/or how to make those objects inherited   from   parent to child table?

Thanks lot!

Jerry

[Chuck Tomasi]

Business rules ARE inherited. It is likely that the BR is running, triggering an event, but the notification is tied to the parent table. You may just need to duplicate that notification and change the table so it can get the record information (especially the fields specific to the child table.)

If you are using Geneva, use the Preview Notification button to test how the notification will be triggered and who it gets sent to.

Email Notifications - ServiceNow Wiki

[Chris M3]

From recent personal experience, triggering an event against a different table does not prevent the notification from being sent, so I do not believe this would be it.   In our case, project.on_hold was being triggered from an enhancement record, and the notification, which had the Project table selected, was still being sent out.

*edit* This is on Geneva

[jzhou]

Hi ctomas,

Thanks lot for your help!! I am using Geneva version. That particular notification "incident opened for me" is running against the Caller_id, shown on both the incident and my extended table. I tried duplicate the notification and changed the table from incident to my extended table the other day, it did work!. But my true question is: from administrator training class and documentation I see, this is supposed to be inherited over, i.e should fire on the child table without doing anything, just like UI actions, right? Or there are still some conditions that some of the notification will be inherited and some of them will not and needs to work around like this one? If so I would appreciate it very much if could you anyone point to me more detailed/comprehensive documentations on these artifacts inheritance subject such as, make the table extensible, make the UI policy inherit, or what will be unconditional inherited, what will be inherited under some conditions, etc.

Thanks lot!

Jerry Zhou - ITIL v3, PMP, PhD

Principal Application Architect

202.418.7426 DIRECT

jzhou@THEAMBITGROUP.COM<mailto:jzhou@THEAMBITGROUP.COM>

www.theambitgroup.com<http://www.theambitgroup.com>

facebook.com/TheAmbitGroup<https://www.facebook.com/TheAmbitGroup>

twitter.com/TheAmbitGroup<https://twitter.com/TheAmbitGroup>

WE GET THE MISSION OF GOVERNMENT DONE.

Smarter. Faster. And cheaper.

[Chris M3]

If your table is truely extended, then that logic exists on your extended table.   However, there may be conditions that prevent it from running, and those conditions could be in many places.

Class = Incident would not run for your extended table

Class IS A Incident would run.   I doubt any OOB logic would use this as a condition.

In the OOB incident events, I don't see anything that would prevent it from running on an extended table.   So, I question whether what you did was actually extend it.   If you go to the incident table, do you see the records in that table for your extended table?   You mention Parent/Child, did you actually just create a child record of Incident (like Incident Task)