Know the Dataverse, Solution, and Publisher

Why are Solutions a new feature in FetchXML Builder?

Solutions have nothing to do when we’re working with queries, right?
So why is this the best feature I have released this last year, or longer?

I know, the subject seems like a crazy big blog…
…anyway, go on and see why you should know it!

---

Know the Dataverse

Dataverse is awesome, and it’s big…
If you have a standard install, it has 1000+ tables, and columns are uncountable… (almost)

So you can get lost with a gazillion entities and attributes. This is why the metadata properties can filter, say which should be shown in the tool, to hide these you don’t need. But it is hard to set the right metadata you need. It’s a bit hard to know the metadata too.

The Problem

For many years, you can filter which to show in the FetchXML Builder by their metadata properties. This stores if a table is eg. a flag if it is managed or unmanaged, or a flag showing if it’s a custom table or a standard table. There are more metadata properties for filtering, but it may be hard to use it – for me too!

A very common issue: if I want to see “my” table rapp_rocket and the from Microsoft table account, I can’t filter with “unmanaged” (created in my environment) or “custom” (not created by Microsoft core) – I can’t make it show without showing everything.

Why use Dataverse? 🤔

Sorry – that’s not the discussion right here – I have worked with Dataverse, CDS, XRM and CRM for many years… Of course, I use Dataverse because… well – it’s the best. Period. If you don’t agree – go read here.

---

Know the Solutions

The Solutions exist because we have to be able to move the systems. Started in 2011, with Microsoft Dynamics CRM 2011 version, to start sharing our awesome solutions. It contains all entities and attributes and optionsets and forms and views and Flows and… well everything we need to deploy your system!

No solution 😱

I know, it is still possible to create a new table in the Default solution – a “no solution” – and they will be called new_mytable, and sure, that works…

But you cannot export that solution, the Default solution by the definition contains everything. That’s great to get a full copy of your system. But you can’t. And you shouldn’t.

Don’t use it. Ok? Promise.

Your solution 🙂

If you are working with just one environment, you should anyway have a proper solution – a nice name, a good prefix, and so on.

Why? Because you can easily see what you have added, and what you have changed – and you are able to export the solution at least to get a backup of your system. The solution is in an unmanaged state.

Your vendor’s solutions 🥰

Most companies have a vendor to make your perfect tailored system. (If you don’t – call me 😉)

Even if your vendor is from a consultant company, or from your internal IT department – it is important either way.

I hope the vendor knows the tech we work with, and they should deliver the solutions in a managed state. (If they don’t – call me today 😬) This makes it still possible to make changes in your production environment, unfortunate. Microsoft (and me too) have been talking about this “lockdown” production environment for years and years, but it is still not possible to lock the prod yet. One day… 🙏

Either if you get one solution or many solutions, it’s very good to see where you find the tables, columns, and everything else in there. They are in the solution! (If not – call me now 😣)

---

Know the Publisher

The Publisher has information about you, I mean your company. A name, a website, phone number, and email, and maybe a physical address too. They are basically used for one thing – the solutions.

You find these under Solutions, and tab Publishers.

Vanilla Publishers

See what we have, before creating any other publisher:

One is not showing (but of course in FetchXML Builder) is the MicrosoftCorporation. That is used as the core solutions, that are installed when you create a new environment.

Two more from Microsoft developments that are showing and are readonly, the microsoftdynamics and the Dynamics 365. Why so different names? I don’t know, and to be honest, I don’t really like it… Why not make a proper Display name? You’ve had a decade to fix it…

We have three Default publishers.

• Default Publisher for <original instance URL>
  This has EVERY things in your environment, even if the components are created manually or from your imported or from MS updated/import solutions.
• CDS Default Publisher
  MS has created this for you to use. I think it’s a bad thing to do. If you need it for creating solutions, you should create your own publisher! And why do we still see the “CDS” in the name…? Ouch.
• Default Publisher for CITTest
  It is importing a bunch of solutions, which you probably need. But the name looks a lot like another “default publisher”, and it is not a readonly one. How do we use it? Shall we? Shouldn’t we? I think not… Do you know more about this?

When you create a new solution, you have to select a publisher. You can use the Default Publisher for xyz. It is way too easy to start creating a solution and you’re stuck with a default publisher and a really ugly prefix. That’s bad, with all “Default” publishers. Just don’t.

Create a Publisher

Most time, this is done once only, and you use it for all new solutions. I mean you should. I do it. Promise.

You enter the Display name, the technical Name, and the Prefix.

Use the Publisher

Make sure to use it too…

When you create a Solution, use set the Publisher you created.

The main things you get is 1) the name of the creator/company and 2) the prefix you want.

What is Prefix?

They are used for the technical names of tables, columns, etc. When I create my table Rocket the logical name will be rapp_rocket. It shall be less problem with table names conflict with other creators, you can see a difference between rapp_rocket and nasa_rocket and even musk_rocket.

---

Why are we talking about this?

Ok, now you know about Dataverse, Solution, and Publisher, the really simple things. And I know you will now use it properly. Great.

(Read more details about Dataverse Solutions explained by Benedikt Bergmann!)

As I said, the Dataverse is awesome and HUGE. Which also means you can get lost inside the Dataverse…

Now you start to see why…

You can either Search for tables or columns when you want to build a query. Or you can Filter them…

---

Filter in the FetchXML Builder

There’s a new feature released (version 1.2022.5) that you can easily filter the tables (entities) and columns (attributes) by a Solution or by a Publisher.

If you filter by a solution, you will see not only tables and columns that were created in this solution, but also all components that I have added already existing! If my solution works with my two new tables Rocket and Mission, it also works with the core tables Account and Contact.

You know that Accounts is actually a BIG table… hundreds of columns… too many columns for me. So you add the columns you need to see, to work with, and make them part of your solution.

The Account table works – in my solution – with two standard columns that are managed, and one Authorize Space as a created column, here unmanaged.

If my system is spread to more solutions, I can filter by the Publisher.

It will now show all tables and columns that are in any of the solutions with this publisher.

---