Also Known As / Trading As name for Account

[AdamVero]

A customisation I often do is to add an extra test field to Account entity for "Also Known As" or "Trading As". Name might be some combination of these eg "Trading As / AKA". This field is added to the Quick Find fields for searching. Intent:

• encourage (or require) users to put full legal name as the Account name (OOB field). Especially important if Accounts are also used for ERP / financials and synchronised there.
• at the same time enable users to search based on another name or abbreviation the company is known as publicly or colloquially.
• enable users to enter any name in this field that they think someone might type in when trying to search for this record in future
• Avoid having to use wildcards to avoid typing high-frequency or longer words (eg "University of...", or even just "The...") as this can lead to many false positives in search results eg "*Manchester"

Use cases:

• website branding or abbreviated names are often different from actual incorporated name but might come to mind first when searching
• public sector and education in particular often use abbreviations or acronyms when names are very long, and especially when many start with the same words (prisons, universities). Examples: HMP Dartmoor, DEFRA, UMIST, UWE etc
• organisations known colloquially by a name which is the "wrong way round" from their official title eg Oxford University cf The University of Oxford
• companies formed by mergers where they might still be known in one country or another more by one name than another. Daimler-Chrysler cf Daimler cf Chrysler
• company names which are commonly mis-spelled or wrongly abbreviated. Does "Sainsbury's" have an apostrophe? Coca Cola? or Coca-Cola? IBM or I.B.M. or International Business Machines?

This simple field can give users a lot of control over future search terms, keep actual Account names more accurate, and improve search results at the same time. Is this the sort of thing that would make sense to offer as a schema extension? Or ami I barking up the wrong tree here?

[cseymr]

I think this sounds exactly like the right sort of thing.

But it got me thinking - how does one make a schema which deals with that AND deals with an Account having multiple Trading Names/AKA; perhaps a delimited long text field might do it, but what if you then want to tag the names as 'Website', 'Legal name in Scotland', '...'.

So, the complexity builds, and the utility is going down (probably, for most people); so I suppose the question for Sarah and Scott is - how do you decide when the Schema extension is getting too complicated to be helpful?

[scottdurow]

So the question seems to be "do we have a simple text field or a 1:N relationship to an Additional Name entity"

My view is that we should aim to serve both the simple and complex implementation but be consistent between both. We could achieve this perhaps by having both the field and the additional name - with the additional name records being automatically flattened into a comma separated list in the text field.

[AdamVero]

The field needs to be on the relevant entity (Account in this case) in order for Quick Search to do anything useful. Using a related entity and automating a comma separated list only works on the main entity if wildcards are used in the search, so there needs to be some sense of the "primary" additional name, so this can go first in the list and be picked up even without wildcards. Even more additional fields for searching might also be useful - website already exists but again suffers from http and www getting inthe way of using it for search, so a similar extension could be to add "Domain name" as a new searchable field (and automate parsing website or email address to get this, don't put it on the form etc). But again do we then have to extend as a 1:N related entity for the case of many domain names?

Fictitious example: Possum Insurance, known to everyone by this name because of their controversial TV ads where furry vermin get run over - tagline "Don't miss a possum!". Legal name: Boring Car Insurance (UK) Ltd. Suggested data we might store and want to search: Account name: Boring Car Insurance Plc. AKA / Trading As (schema extension): Possum Insurance Website: www.dontmissapossum.com Domain name (schema extension): dontmissapossum.com Parent company: Boring Insurance (UK) Plc (searchable for "Boring Ins.." instead of "Boring Car..." Ultimate parent company (derived through automation): Very Boring Holdings Plc.

Overall, I think the question has to be "what is the purpose of this proposed extension?" If it is to thoroughly document everything we know about an Account, then lots of related entities might be needed. If it is to make it easy for a user to enter an alternative name so that they and others can find a record again rather than getting zero results for UMIST when they should have typed "The University of Manchester Insititute of Science and Technology", then a single text field should do the job. When I do add such a field, my training for users says to them that if they search and don't find something, then figure out how to get to the record (using other terms, or by finding a Contact and working upwards), they should update the "AKA" field with whatever they searched for the first time.

Thinking bigger: Using global search instead of quick search changes the game - you could include the related entity as a searchable entity and call it something like "Alternative names". It would of course need lookup fields to all possible entities it might relate to in order to make it as multi-purpose as possible for leads, contacts, accounts, users, competitors (anything that might go by some "nickname", really). This still does not help when the user uses quick search, so I think I am now suggesting this: A field on the Account record for "Also known as", which is searchable A 1:N relationship to "Alternative names" entity. When an "Alternative name" record is created, name is copied to parent record if that has no "AKA" value already. "Alternative name" record can be marked as primary, in which case name is copied to parent regardless of current value. Also needs to find previous "primary" name to un-mark it.

These could co-exist - simple text field for simple use cases, extended related entity version added over the top for complex cases.

Aside: You can't have one legal name in England and a different legal name in Scotland. You incorporate in "England and Wales", OR in Scotland. If you incorporate in both, that's two companies with two numbers and I would argue that's two account records with some kind of relationship (parent / child, or via a connection or whatever). Of course you can have multiple trading names, brands, domain names etc., but not two legal name. Just sayin'

[cseymr]

So, a little like addresses? You can enter an address into a Contact/Account without ever being aware how the Address entity is working for you underneath. But if you know about the Address entity, you can do cleverer stuff.

The key (for me) to making that work is the same way in which the CRM SDK works so well - excellent documentation, examples and signposting within the documentation.

As for the Scottish question - I shall defer to your wisdom ;-)