Creating an "also known as" table or a single slicer that searches multiple tables

[ChrisR22]

Hello,

I am in a situation in which I am pulling data from numerious different platforms, all referencing client activity data. Each platform might spell the client's name slightly differently, be it capitalizations or spaces. The end goal is to be able to have a slicer that can capture all of these variations.

ex.

Apple

APPL

Apple Inc.

APPLEINC.

It seems my options are:

- create a table of similar names in which I can mark these 'aka' names and then have a single slicer catch all variations of the name

- a way for a slicer to search the 'Client' column of 5+ different tables, that way as I begin to type the name all the variations will pop up and I can just select all of them. Less elegant but might be simpler

If anyone has any other clever solutions those would also be encouraged.

Thanks in advance for your assistance!

[samdthompson]

Hello, No, slicers wont search through multiple table. Im suggesting using PQ to create a tables of all the names which you would use to join them all. A slicer would be from which ever column on that table has you most unified version of the names. Since PQ is a set of rules that would be applied each time you are loading the data, so no redoing. Bit hard to tell without seeing it all but i imagine some table thats taking all the say name columns and appending or perhaps some fuzzy merging and then the actual cleaning. It wont make a perfect set of names but could be made better as time goes by and you ID traits in the names or known exceptions that have to be taken into account. 

Cheers,

[ChrisR22]

But there doesn't appear to be a way for a slicer to search through mutiple tables, unless I am missing something?

And what sort of manipulations are you suggesting? Unfortunately I cannot just individually update the names in PQ because every month I reload the data from an external source, so the corrections would need to be executed on a montly basis.

[samdthompson]

Hello, your second solution is the most robust as the first is too binary and you are much more likely to miss some info. If it were me, I'd do some manipulation in PQ of some of the more common differences in the systems and do some alignment of the names, no doubt there are some easy wins. Ideally of course there is some unique ID number but i get thats not always the case.

Cheers,

[ChrisR22]

@samdthompson what sort of manipulations are you suggesting? Unfortunately I cannot just individually update the names in PQ because every month I reload the data from an external source, so the corrections would need to be executed on a montly basis.

Would you create a new table of similar name, and if so how would you structure it?