Explore
Explore is for looking around. You don't need a question yet, and you don't need to know what anything is called.
It is the fastest way to see which records are available before deciding what to ask.
Browsing by kind
The left rail lists the records available to you with a count next to each type: accounts, tickets, centers, repositories, and more. Pick a type to see the list, then open an item to see its fields.
The counts are worth reading on their own. If you connected Salesforce this morning and expected 4,000 accounts but the rail says 40, discovery is still running or the connection is scoped more narrowly than you thought.
If the rail is empty, nothing has been discovered yet. Connect a source and it fills in.
Searching
Search filters within the kind you're looking at. It matches names, so it's for finding a specific thing you can already name.
If you're trying to find things by a property rather than a name, that's a question, and chat is better at it. "Accounts in Ohio with no owner" is a question. "Acme Corp" is a search.
Scoping to a view
A view is a named set of records, such as the accounts one team owns, the services in one region, or the centers above a size threshold. If your team uses views, you can narrow Explore to the relevant set.
Views are worth asking for if you keep filtering to the same subset by hand.
Rolling back the clock
Explore has a time control, and it does more than filter by date. It rebuilds the view as of the instant you choose.
Set it to three months ago to see the records and values that were available then. You are not looking at today’s data behind a filter. You are looking at the state your team would have seen in May.
This answers the question that usually can't be answered: not "what is our pipeline" but "what did we think our pipeline was, before it changed."
The control shows how far back your data goes, so it isn't a guessing game. Ask for a date before your first discovery run and there's nothing there to show, which is honest rather than empty.
In a demo or training workspace pinned to a fixed date, "three months ago" means three months before that date.
Looking at one thing
Open an entity and you get its fields, and every field can be traced.
Click into a value and you'll see which system it came from, when it was last true, and what other systems said if they disagreed. That last part is the one people find useful and unsettling in equal measure. Two systems holding different industries for the same account is normal. Seeing it stated plainly is new.
See Trust and control for how SixDegree presents the evidence behind an answer.
From an entity you can also:
Open related records to see what connects to it. This helps you find relationships that are not obvious from one system alone.
Ask about it to start a question with the record already in context.
Going the other way
Answers hand off to Explore too. When chat returns a set of things, you can open that set here and browse it item by item.
Use it when an answer says "seventeen accounts" and you want to look at all seventeen rather than trust the number. Reading the list is often how you notice that two of them are the same company entered twice.
When something looks wrong
Explore is usually where you notice a problem, so it's worth knowing what the common ones look like.
A count is lower than you expect. Discovery may still be running, or the source connection is scoped to a subset. Check the source under Build.
The same company appears twice. Two systems disagree about identity and haven't been matched yet. That's the identity review queue's job.
A field is empty that shouldn't be. Trace it. An empty field with a recorded reason (the lookup found nothing) is different from a field nobody ever mapped.
A field is marked restricted. It exists, but you do not have access to it. Ask the person who manages access for your team.