3 ways to get the Organization URL in your Plug-in

Have you ever found yourself in a situation where you wanted to get the current ogranization URL from a plug-in? You’ve had to generate a URL for the record? Call the OData API for some reason? Whatever the reason might be, let me show you three ways to achieve this!

In a Power Platform plug-in assembly, you have multiple options to get the URL of the current organization. Each of them has their pros and cons, but let’s see your options as of today.

1. RetrieveCurrentOrganizationRequest (recommended)

The RetrieveCurrentOrganizationRequest class is one of the requests supported by the OrganizationService and would be the easiest and most recommended way! Its counterpart RetrieveCurrentOrganizationResponse class does not only contain the endpoint URLs, but detailed information about the organization such as unique name, location, version, and such.

The usage of the request is straightforward:

var request = new RetrieveCurrentOrganizationRequest();
var response = (RetrieveCurrentOrganizationResponse)localPluginContext.OrganizationService.Execute(request);
if (response != null)
{
    localPluginContext.Trace($"Endpoints: {String.Join(", ", response.Detail.Endpoints.Select(e => String.Concat(e.Key, ": ", e.Value)))}");
}

The output in the trace log would be something like this:

[+0ms] - [ExecuteDataversePlugin] - Endpoints:
WebApplication: https://org***.crm4.dynamics.com/, 
OrganizationService: https://org***.api.crm4.dynamics.com/XRMServices/2011/Organization.svc,
OrganizationDataService: https://org***.api.crm4.dynamics.com/XRMServices/2011/OrganizationData.svc

As you can see, the endpoints of the response will be a dictionary, containing three URLs:

• WebApplication: The full URL of the current environment
• OrganizationService: The URL of the organization service (used by IOrganizationService)
• OrganizationDataService: The URL of the organization data service (preferred for client-side development)

Pros:

• Extremely easy to implement
• Always returns the information about the current environment
• No pre-configuration necessary

Cons:

• A bit difficult to use outside of plug-in assembly (e.g.: Power Automate, JS)

2. Environment Variables

Have you already heard about environment variables? You can use it to store environment specific configuration data in it. Not to mention that it can be easily included in your application lifecycle management (ALM) processes. You could easily create one environment variable, that would store your environment URL in each of your environments.

Retrieving the value of such environment variable can be done as follows:

string variableName = "EnvironmentUrl";

var query = new QueryExpression("environmentvariablevalue");
query.ColumnSet.AddColumns("value");
var query_environmentvariabledefinition = query.AddLink(
    "environmentvariabledefinition",
    "environmentvariabledefinitionid",
    "environmentvariabledefinitionid"
);

query_environmentvariabledefinition.LinkCriteria.AddCondition("displayname", ConditionOperator.Equal, variableName);

var response = context.OrganizationService.RetrieveMultiple(query);

var value = response.Entities.FirstOrDefault()?["value"];

The returned record(s) will contain the value of the variable in the value field.

Pros:

• Supported everywhere, including plug-ins, cloud flows, javascript, etc.
• Can be used for many other things as well.

Cons:

• Configuration necessary per environment.
• A bit difficult to retrieve the value from a plug-in code.

3. Plug-in step configuration

I must admit, I have never, ever used plug-in step configurations before. This doesn’t mean it is useless, in fact it can come to our rescue in this case as well!

When you register a plug-in step, you have the option to pass an unsecure and secure configuration with it. Keep in mind, you must specify the configuration in XML format!

The configuration data can be accessed within your plug-in’s constructor as string parameters:

public SamplePlugin()  
public SamplePlugin(string unsecure)  
public SamplePlugin(string unsecure, string secure)

From here on, you just have to parse the XML with the correct schema and extract the data you need – such as the environment url. Refer to the image below for an example configuration:

Pros:

• Can be used to pass any data to your plug-ins.
• Supports secure configuration for sensitive data.

Cons:

• Configuration necessary per environment.
• Only supports XML schema.
• Can only be used in plug-ins.

Conclusion

As you can see, there are multiple ways to get the current environment’s url, which might come in handy in several situations. While environment variables and plug-in step configurations are great features on their own, I would recommend them for other scenarios, but sticking with the first option this time!