Does a view rule automatically apply to child tables?

[scottatah]

On our change_request table, we have an 'emergencyChange' view.   When I look at the view rule, the table is change_request and the condition is type is emergency.   Pretty straight forward.   When I look at the UI view itself, there is nothing on there that suggests it would apply to the change_task table.   Furthermore, there are no view rules applying to the change_task of table of any sort.

When I personalize the form design of the change_task table, I see there is an 'Emergency' view which had a few peculiar things setup (i.e. pulling the change request.work notes and the change request.comments and work notes, where as the non-emerg view simply shows the change task worknotes and activities.

The reason I discovered this is (and this may help you smarter folks) when you navigate to a change_task of an emergency change via a link or a global search, you get the non-emergency view.   However, if you click into via the task-list from the parent change, you're brought to the emergency view.

I'm slightly torn as to how the change_task form SHOULD be displaying, but I'm trying to get a better understanding of how the views are supposed to work.   There's nothing in view management on the wiki that really gives off extra info.  

http://wiki.servicenow.com/index.php?title=View_Management#gsc.tab=0

It should be noted that we're still on Eureka at the moment.

I've tested the same thing in Helsinki patch 8 (which we're upgrading to) and I cannot mysteriously get into the 'emergency' view of a change_task without switching to it as an admin, which is nice, however, the view still exists in the personalize form layout - which makes sense since it probably just carried across from our production environment.

Thanks in advance.

[Joe McCarty1 · Accepted solution]

I don't think it is the view rule that is directing you to the emergency view.   View rules as far as I recall only apply to the specific table in the rule and not extended tables.   But the change_task table does not extend change_request anyway and is only related to it so I wouldn't expect it to inherit behavior/fields from change request.

What I think you are seeing is the behavior on all related lists.   All related lists (even outside of change) will use the current view of the form they are invoked from.   In the event that that view doesn't exist on that record type it falls through to the default view.   But if someone configured on the related form while using the parent's view it will fork off a new view from the default.

If you like having separate change tasks views per type so you can customize the form you can add new view rules that have a dot-walked condition to change_request.type = emergency such that the global search will honor that too rather than just relying on the related list to drive the view from the form.

If the forms need to be the same, you can either synchronize the views or delete all but the 'default' view of the change task forms.   If you do the latter you'll need to take care in the future to make your changes on the default view or you will fork off a new view again.

Hope this helps.