Company.customer field - intended use and other quandries

[Les1]

All, I'd like some background and assistance understanding the company.customer field and its relationship with the rest of the company record and other fields.  Sorry for the length, and hope this helps new admins. if anything below is incorrect or not intended OOB, perhaps i'm observing an issue in our instance that needs further investigation. let me know. Thanks!

From what i can tell there are a few designations (or 4 if you count 'no designation'): Manufacturer, Vendor, Customer, or again, no designation

some aspects that seem confusing so maybe someone can explain intention:

1. in Madrid, When navigating to Organization / Companies  the List View = Customer
2. 1. the effect from this is that opening a record also is in Customer View which only shows the Customer designation as able to be set. (the other two designations are not displayed)
   2. if changing the view to Default, oddly the other two designations are now displayed, but the Customer designation is now hidden from the layout
3. When going to documentation https://docs.servicenow.com/bundle/madrid-platform-administration/page/administer/users-and-groups/t...  the Customer field is absent from being elaborated on, i was unable to find anywhere in documentation that mentions the Customer field in my short searching around.
4. Any issue with a company record having more than one designation: ie, a Customer AND Manufacturer 
5. Can someone elaborate on the above and help with intended use of these fields, the obvious intent to me would be designating records using the 3 options (or no option) but its puzzling why Customer seems segregated as an option. Sure its relatively easy to adjust with customization, but why not be OOB?

There is some impact to other areas of the platform, namely Incident in which 3 fields: Caller, Location, and Configuration Item have a Dependent On = Company (Incident.company) and there is a business rule that sets the incident.company field to be = Callers company (from user record). Thus the caller's company would be reference qualifier for these other fields. Further, incident.company has a dictionary reference qualifier of "Customer = true" so only those companies in your companies table designated as Customer will show on incident.company. Further, OOB on the Incident form, incident.company isn't shown. This could lead to confusion if the above isn't understood, as when the incident is saved for a caller (and thus the incident.company record gets populated) if trying to set the configuration item, or location, or if trying to change the Caller to a different Caller ,all will be Dependent on the incident.company value which is now set to the original caller's company - so you're not going to see anyone/anything else but for that company. if you have multiple companies this could be confusing, especially with Company not displayed on incident.

Before i made customization I wanted to ensure i was understanding the OOB intent. Thanks in advance!!

[jMarshal · Accepted solution]

> in Madrid, When navigating to Organization / Companies  the List View = Customer
> the effect from this is that opening a record also is in Customer View which only shows
> the Customer designation as able to be set. (the other two designations are not displayed)

This is how the Now Platform usually functions (the view that is on the list is the view applied to the record that you opened from that list)...I think the only way around that is to not have the view available on the record, in which case it will go to the "default" view...but I haven't tested that theory yet.

> if changing the view to Default, oddly the other two designations are now displayed,
> but the Customer designation is now hidden from the layout

You should be able to "configure form design/layout" to modify the default view, to include that field, if desired. Though I agree that it is somewhat confusing that the Now Platform's default view for the [core_company] table doesn't include that field...not sure what the intent is for that OOB, sorry.

> When going to documentation https://docs.servicenow.com/bundle/madrid-platform-administration/
> page/administer/users-and-groups/task/t_AddANewCompany.html  the Customer field is absent from
> being elaborated on, i was unable to find anywhere in documentation that mentions the Customer field
> in my short searching around.

I believe the OOB intent of this field is to identify a company in that table as a customer of YOURS (they consume your products/services). This way other OOB features that treat users in that company as customers, would likely be able to look to that field to identify as such...I think you'll have to see what features those may be though as I am not sure and it doesn't seem to be heavily published. Perhaps someone else has some more insight regarding that, specifically.

> Any issue with a company record having more than one designation: ie, a Customer AND Manufacturer 

Sorry that I don't have any authoritative knowledge here...but I would be extremely surprised if there was any issue with this. Using check boxes for those attributes would strongly suggest that they are not mutually exclusive. It is also very normal (conceptually) to deal with a company that has both the attributes of consuming services from you as well as providing services to you.

> Can someone elaborate on the above and help with intended use of these fields, the obvious intent
> to me would be designating records using the 3 options (or no option) but its puzzling why Customer
> seems segregated as an option. Sure its relatively easy to adjust with customization, but why not be OOB?

Unfortunately, I don't think I really answered the crux of your query (the Now Platform intent for that field and why it seems to be at odds with what would be natural/intuitive for a field like that).

Hopefully I can provide some solace to you in that I am also a relatively new admin (< 2 years) and I've seen stranger OOB configurations...and from what I can tell, these odd OOB configurations are due to organic growth, where one field's intent changes over time or grows beyond what the initial intent of that field (or configuration/feature) was.

> There is some impact to other areas of the platform, namely Incident in which 3 fields:
> Caller, Location, and Configuration Item have a Dependent On = Company (Incident.company)
> and there is a business rule that sets the incident.company field to be = Callers company
> (from user record). Thus the caller's company would be reference qualifier for these other fields.
> Further, incident.company has a dictionary reference qualifier of "Customer = true" so only those
> companies in your companies table designated as Customer will show on incident.company.

Good job! This is literally the type of work you need to do to determine these types of things! In our instance we just removed those dependencies as all of our customers are internal...but this is the intuitive interaction of that field that suggests (to me) that my responses above (and what you probably already assumed) are just what you need to be concerned with (and should work if you just use them in that way).

This still doesn't explain why the "customer" field is absent from the default view for the core_customer table...but that's where I would just fall back to the "changing intent via organic growth of the product over time" logic.

> Further, OOB on the Incident form, incident.company isn't shown. This could lead to confusion if
> the above isn't understood,

Unfortunately, this is true...I think ServiceNow relies on you having all of that well configured and explained to your end-users before going live (you wouldn't need to worry about those potential conflicts because they should be accounted for with your data load).

...basically assuming that you would never accidentally add a customer that didn't belong to a company that you have already identified as customers, because you should just have that done already.

Another line of thought is that those controls allow you to identify gaps - if you can't appropriately change the value of the caller, it could be that they are not associated with the correct company (go fix that in the customer table, because that is work that needs to be done anyway) and THEN go back to the incident and update the record appropriately.

In theory, great - but I totally understand how that may not fit your company's workflows very well (incident resolution is primarily about speed, after all).

> Before i made customization I wanted to ensure i was understanding the OOB intent. Thanks in advance!!

I'm not sure I helped all that much with outlining the Now Platform's actual intent of that field...but hopefully, if you don't get any better responses, I've helped settle your mind a bit!

[Les1]

applaud you for thoroughly responding to my narrative!   for a couple days I had journeyed through frustration while investigating why after we had just upgraded to Madrid, were having odd and impacting issues with Incident form due to the dependencies that you graciously provided input on.  The real fuel for fire for me still remains that I still wasnt able to determine why the dependencies seem to arise recently vs something we should have experienced previously as they do not appear to be linked to just upgrading (unless some customization previously made had been reverted to OOB which my gut tells me is likely the answer - i just havent found what customization that would have been).

We also consider all of our customers as 'internal' so i've just turned off these field dependencies as well.

Thanks for listening and providing input!