How to find which Power BI source Excel is connected to.

Microsoft are increasingly trying to get users to store data in Fabric and then access them from other sources, be it Power BI or Excel. It's great to be able to do this, but the problems come when you can't remember where you got the data from. How can you work your way back to that?

Excel is particularly unhelpful in this respect if you have a connection direct to a table on a tab in the front end (i.e. not going via Power Query). You can click on the relevant connection in the Connections window (Data/Queries and Connections) but then it's remarkably coy about finding anything else. 

I have figured out the way to find your way back.

1. Right click on the relevant connection and choose Properties 

2. Click on the definition tab. The information you need is in the "Connection string" window.* 

3. The key bit of text you need is called the "datasetID". This is the long string that will be something like: 842gh54e-1567-56b9-jklt-52375621321g. I don't know how much the text varies in this box, but for the ones I'm looking at it comes after "wowvirtualserver-" under "Catalog"

4. Once you have the datasetID you can drop it into this url:
https://app.powerbi.com/onelake/details/dataset/<DatasetID>/overview?experience=power-bi, so in this case:
https://app.powerbi.com/onelake/details/dataset/842gh54e-1567-56b9-jklt-52375621321g/overview?experience=power-bi

This takes you through to the Onelake page for the dataset which has the Dataset (Semantic model)  name in the top left and the Workspace name a little under that under "Location".

Thus is you need to make changes, want to see how often it refreshes, or just work out where it's coming from.

*There is also the "Command text" window here, which gives you details of the DAX used to create the Excel table)

How does Five9's call log code its calls?

I'm just about hanging on to the desire to occasionally blog in the light of the AI juggernaut, but lets face it, no-one's finding this, I'm just writing for myself.

Anyway, trying to identify what data Five9 produces when a customer's call is less than straightforward  is a bit of a headache. So here's what I've found. I'm assuming here that you're running a Call Log report without any filters.

I'm going to look at 5 situations.

1. When a call is transferred ("Third-party")

This is perhaps the most confusing because Five9 create 3 lines in its call log reports for "3rd party" transfers. I use the quote marks because this can include internal re-directs including those from a different leg of the IVR. 

• The first is the call coming in to the original queue (Call type = "Inbound"), 
• then the redirect gets the type "3rd party transfer" – so this gets its own line in the report. Neither line gets a "Skill", so filtering out on this basis can be useful.
• Then you get that 3rd and final line (type = "Inbound" again, but this time it gets a Skill as the customer's chosen option is applied). 

All should have roughly the same value for "Time" though the first line will be slightly earlier and the "Call Time" will be longer by the same margin.

2. When a Callback is requested

This also delivered over two lines. 

• The first is the original incoming call (call type "Inbound"). This also gets a 1 in the QCR column. 
• The second is the actual call-back being executed (call type "Queue Callback") with a 0 in the QCR column, but a 1 in the "Queue Callback Processing" column. 

Unlike the above there will usually be a significant gap in the Time. The figure in the Call Time column for the second row is the time the return call (the callback) took. Both lines get a Skill.
The two exception are if the callback drops or is duplicated – see points 4 & 5 below – where you only get 1 line.

3. Both together

If both these scenarios happen together you should get 4 lines on the call log report which line up like follows:

1. Inbound call
2. The call being transferred to the correct queue, creating...
3. The call that asks for a callback, which then, later in the day, leads to...
4. The actual return call.

4. Callbacks are not always honoured!

Not all callers that request a callback will necessarily get one that day. In extreme situations you might get 100 requests but there will only be time to call 60 of these back. There's a setting on Five9 in which you can determine how long a call will remain on the call list for, so if you don't get to that call in time it will get dropped. These will give you only line (unless it's transferred), with a 1 in QCR. It gets a Skill and a Type of "Inbound". Crucially, they also get a Disposition of "Queue Callback Timeout".

5. If a caller makes a 2nd request for a callback

In this case again you just get a single line, with a 1 in QCR. It gets a Skill and a Type of "Inbound". As with dropped callbacks, these also get a Disposition here it's " Duplicated Callback Request".