Dynamics 365 portals Spring Roadmap and Portal Source Code

If you frequent the Dynamics 365 Roadmap site (built on portals 🙂 ) you may notice a new area has been added for the CRM based Applications (Sales, Customer Service, Field Service, Project Service) for portals features. A number of items for all areas of Dynamics 365 has been posted as we near the Spring release of Dynamics 365 (v8.3), but this is a first for the portal to have been posted which seems to be the makings of a Spring Roadmap for the product. There are some exciting items on there including a release of the portal source code, Azure AD B2C and more. Below is all the items posted to the roadmap as well as some comments on each.

Let’s get to the big one first, portal source code.

Source code for Portals
A one time release of Portals code will be released to the Microsoft Download Center under MIT license for developers to download.

This feature enables Portals to be deployed to Dynamics 365 on-premise environments, and allows developers to customize the code to suit their specific business needs.

This is a huge news, complete open source of all portals code! This should also be taken with some caution though. Let’s understand what this means.

  • One time release – it will never be updated, ever, ever again.
  • Under MIT License – free, and full open source software (OSS), no direct support from Microsoft.
  • Microsoft Download Center – not taking pull requests, no contributing back to a master branch

Some awesome news but a big caution for corporations looking to invest in a supported product. With it being a one time release it is basically a point in time and will not be updated with bug fixes, new features nor will it be supported by Microsoft. The future is very much still online with portals as a service which will continue to be updated with bug fixes, new features and fully supported by Microsoft. If you choose the OSS path then support could come from partners, or other corporations but they will all come with their own costs and potentially different versions of the portal. Being OSS MIT means that anyone can take the source change it and re-publish it, so we could end up with endless different versions of OSS portals. These are the pitfalls with any OSS product so just be very aware if you are someone interested in it.

If your an on premise customer that was still considering v7 of Adxstudio Portals then you should strongly consider this as the cost is a lot less 😉 (free vs $20k+ and even getting a license). However the same cautions apply and if your looking for a fully supported product then online with portal service is the future of the product. If you were looking at Adxstudio Portals v7 because of it’s event or retail functionality then that is still a gap in the OSS version as well.

For developers, this will be a gold mine for those to see the inner workings of the portals product. Look at how the Adxstudio and Microsoft product teams built features, implemented the CRM SDK, and gain a better understanding of how the product operates or why it does something a certain way or modify it to your liking.

Myself and Adoxio will have more to say on Open Source Portals shortly and the direction Adoxio will be taking.

The next big roadmap item…

Support Azure AD-B2C for Portal authentication using a single sign-on (SSO) configuration

For Portals that require a consumer based login, this feature will now support the ability to:

  • Configure your portal authentication to use a Single Sign-On configuration
  • Support Azure AD-B2C for customer authentication
  • Manage your Portal security in Azure

* depends on Azure AD-B2C availability in the region(s) Portals are deployed

I blogged about B2C working in CRM portals late last year, but at the time B2C while supported in portals was not exactly recommended by Microsoft due to some user experience elements not being as desired. It’s great to see that it will be natively supported and recommended with the user experience elements corrected and even more included features released. I can’t more strongly recommend using B2C as your authentication in the portal and moving your authentication outside of Dynamics 365 so that it can be used by all applications and not just the portal. One identity for all your external applications.

Some other interesting new functionality coming soon:

Post installation language add-ons
This feature makes it easier to manage new additions to the existing portal language support.

Great to see, so many portals start off in 1 language and later want to add additional support and this will make that painless now.

Admin wizard to add an entity to the Portal
Easily publish any entity on your Portal using our new administrative wizard. When data is updated in the entity, it will automatically be available to Portal users who have access to these data.

This is likely a tool that will automatically make entity lists, entity forms, and entity permissions with all the web pages setup for you. Will make exposing new entities in the system extremely easy for out of box functionality.

Portal interaction tracking
Track your customer’s interactions with your Portal and funnel it to Dynamics 365 Customer Intelligence to plot a 360 view.

Sort of like Google Analytics but with all the relationships to your other Dynamics 365 data!

Whew! That is a lot of awesome news of features that are going to be coming to the portals shortly. There are a couple more smaller features, you can checkout the full listing on the roadmap site. The exact release dates for all of these is not mentioned, the earliest would be with the Spring release of portals. Previous releases of portals from Microsoft have typically lagged approximately a month behind the Dynamics 365 release. They could also come in monthly updates between now and the fall release.

We will have to keep an eye on the roadmap for future features being announced!

Dynamics 365 portals: Events and iCalendar Download with Liquid

A popular component of Adxstudio Portals was its event management system, which unfortunately has not made the transition to Dynamics 365 portals. There will be a new event management system coming in the future (as seen at eXtreme365 in Lisbon), which will come with a portal component that will list and allow registration to events. Until then you may still want to create some simple event functionality using the out of box configuration based components that allows you to list events and allow users to add an event to their own calendar. In this post we will use Liquid Templates to create your own display of events from a custom entity with an entity list and an iCalendar download (Add to Calendar button) so that users can add it to their own calendar.

First we are starting with an entity (this could be any entity that already exists or creating a new one) that includes the event information. All you need for an event is really a subject and a date. If you want to get a little more complete then we want a start date, end date, subject, description, location. It’s really up to you and the functionality or detail you want to contain in your event. I am starting with an entity called Group Meetings which includes the following fields:

To display the events on the portal you can use an entity list with a custom web template to create a custom output of the information instead of just a grid/table display. Here is the entity list web template used on xrmvirtual.com (I have removed the paging to keep the code length displayed here brief).

{% assign meetingDetails = sitemarkers["Meeting Details"] %}

{% entitylist id:page.adx_entitylist.id %}
  <div class="meeting-list-body">
    {% entityview id:params.view, search:params.search, order:params.order, page:params.page, pagesize:params.pagesize, metafilter:params.mf %}
      {% if entityview.records == empty %}
        <div class="alert alert-info">
            {% if entitylist.empty_list_text %}
              <p>{{ entitylist.empty_list_text | escape }}</p>
            {% else %}
              <p>No items matching your selected criteria were found.</p>
            {% endif %}
        </div>
      {% else %}
        {% for meeting in entityview.records %}
          <div class="media">
            <div class="media-left jumbotron-icon">
              <span class="fa fa-calendar fa-2"></span>
            </div>
            <div class="media-body">
              <h4 class="media-heading"><a href="{{ meetingDetails.url }}?id={{meeting.id}}">{{meeting.xv_name}}</a></h4>
              <p class="meeting-date">Speaker: <span class="meeting-speaker">{{meeting.xv_primaryspeakerid.name}}</span> | <time datetime="{{meeting.xv_starttime | date_to_iso8601}}"></time></p>
              <div class="meeting-abstract">
                <p>{{meeting.xv_abstract}}</p>
              </div>
              <div class="meeting-actions">
                {% if meeting.xv_recordingposted | false and meeting.xv_recordingurl %}
                  <a href="{{meeting.xv_recordingurl}}" target="_blank" class="btn btn-success btn-sm">
                    <span class="fa fa-video-camera"></span>&nbsp;
                    Download Recording
                  </a>
                {% endif %}
                {% if now < meeting.xv_starttime and meeting.xv_meetingurl %}
                  <a href="{{meeting.xv_meetingurl}}" target="_blank" class="btn btn-primary btn-sm">
                    <span class="fa fa-calendar"></span>&nbsp;
                    Join Meeting
                  </a>
                {% endif %}                
                {% if now < meeting.xv_starttime %}
                  {% assign iCal = sitemarkers["XRM iCal"] %}
                  <a href="{{iCal.Url}}?id={{meeting.id}}" target="_blank" class="btn btn-default btn-sm">
                    <span class="fa fa-calendar-plus-o"></span>&nbsp;
                    Add to Calendar
                  </a>
                {% endif %}
              </div>
            </div>
          </div>
          <hr/>
        {% endfor %}
      {% endif %}
    {% endentityview %}
  </div> 
{% endentitylist %}

If you review the code it is basically taking the entity list that the page references {% entitylist id:page.adx_entitylist.id %}, does a check to make sure the entity view is not empty {% if entityview.records == empty %}, if it is not then it iterates through the items with a for loop {% for meeting in entityview.records %}. Within the for loop we have the individual record with the {{meeting}} object, which we then format the attributes of it with some HTML.

As this entity list template is used for upcoming and past meetings there are also some checks so that we can conditional show certain elements on each meeting, one of those being if there is a meeting URL and we are before the start time then show the join meeting button {% if now < meeting.xv_starttime and meeting.xv_meetingurl %}.

When building an event display the highest requested feature is to provide a download or add to calendar button so that users can easily add the event to their own calendars. With liquid templates we can easily satisfy this requirement. Not well documented and really only 1 public example is the web templates MIME type. With the MIME type field on web template we can actually set a custom type that the browser will use to interpret the content it is trying to process. If you don't set a MIME type then this will default the MIME type to text/html. For browsers to detect the content as calendar data then we can set the MIME type to text/calendar and then within the web template define the standard iCalendar format.

Let's start off with creating a new Web Template called iCal Download Handler. At the bottom of the form fill in the MIME type with text/calendar so that when a browser accesses this content it tries to interpret it using the calendar format. Now for the contents of the web template we want to output the standard iCalendar format. You can read through the entire RFC (if you really want) for iCalendar here to understand all the formatting options. Alternatively you can review the Wikipedia iCalendar document, as well below is a simple single event example.

{% assign meeting = entities.xv_groupmeeting[request.params.id] %}
{% if meeting %}
BEGIN: VCALENDAR
VERSION:2.0
PRODID: -//xrmvirtual.com//NONSGML ical.net 2.1//EN
BEGIN:VEVENT
DTEND:{{meeting.xv_endtime | date_to_iso8601 | remove: '-'}}
DTSTAMP:{{meeting.xv_starttime | date_to_iso8601 | remove: '-'}}
DTSTART:{{meeting.xv_starttime | date_to_iso8601 | remove: '-'}}
SEQUENCE: 0
SUMMARY:{{meeting.xv_name}}
X-ALT-DESC;FMTTYPE=text/html:{{meeting.xv_abstract}} {% if meeting.xv_meetingurl %}<p><a href="{{meeting.xv_meetingurl}}">Join meeting...</a></p>{% endif %}
UID: {{meeting.id}}
END:VEVENT
END:VCALENDAR
{% endif %}

The first check in the template is that we assume the ID of the event we want to provide as a download is provided as a query string parameter called 'id'. We use this parameter and the liquid entities object to retrieve the group meeting record. If the meeting exists then we output the iCalendar format with attributes from the group meeting as values for the iCalendar attributes.

The date/time iCalendar attributes do expect date/times formatted in the ISO8601 format and does not included any dashes. Luckily there are liquid filters that can help us achieve this exact format. Taking the meeting start or end time which is stored as a CRM date/time object we can apply the date_to_iso8601 filter and then apply the string filter to pull out the dashes that are included in that format remove: '-'.

In the SUMMARY attribute just simply use the liquid to expose a CRM attribute from the meeting object, {{meeting.xv_name}}. For the description (abstract in XRM Virtual group meeting) because we are using the CK editor to provide rich text for the description contents this is stored as HTML we need to provide the X-ALT-DESC iCalendar attribute and tell it the format FMTTYPE=text/html so that the encoding is properly interpreted. To this we also add a simple conditional check to see if there is a URL and then include the HTML to generate that link as part of the description. Finally the UID attribute of iCalendar format we just make the CRM GUID of the record.

To make this web template accessible we need to give it a URL. First create a new Page Template with the type of Web Template. Ensure the set the Use Website Header and Footer is not selected and set the Web Template to your iCal Download Handler. It is important that the Use Website Header and Footer is turned off as this will ensure that when this template is rendered it only includes the content in the web template and none of the scaffolding of the portal (like the header and footer HTML). With your page template create a new Web Page that references the new Page Template.

Page Template:

For ease of access in web template I also created a Site Marker that refers to the web page, then used the following code in my event list template to get the URL and pass the ID of the record:

{% assign iCal = sitemarkers["XRM iCal"] %}
<a href="{{iCal.Url}}?id={{meeting.id}}" target="_blank" class="btn btn-default btn-sm">
  <span class="fa fa-calendar-plus-o"></span>&nbsp;
  Add to Calendar
</a>

From this we have taken a custom entity that has event type data and displayed it in a nicely presented format on the portal and included an add to calendar or download calendar item functionality so that users can include it in their own calendar. Now because of the various versions of iCalendar that vendors have implemented you may notice this iCalendar format does not work on every device, you can though create specific web/liquid templates for the various formats and provide links to each of them or you can look at JavaScript libraries that help provide this format. AddEvent is a common plugin that can be used freely for personal use and licensed for commercial sites that will provide an easy implementation in a web template (below is a sample) that will cover all iCalendar formats.

AddEvent Liquid Template Sample:

<span class="addtocalendar  atc-style-blue">
  <var class="atc_event">
    <var class="atc_date_start">{{ event.adoxio_startdate | date: 'yyyy-MM-dd hh:mm:ss' }}</var>
    <var class="atc_date_end">{{ event.adoxio_enddate | date: 'yyyy-MM-dd hh:mm:ss' }}</var>
    <var class="atc_timezone">America/Vancouver</var>
    <var class="atc_title">{{ event.adoxio_name }}</var>
    <var class="atc_description">{{ event.adoxio_name }}</var>
    <var class="atc_location">{{ event.adoxio_name }}</var>
    <var class="atc_organizer">City of Victoria</var>
    <var class="atc_organizer_email">info@adoxio.com</var>
  </var>
</span>

Determine your Dynamics 365 portal data center

When you deploy a portal for Dynamics 365 you always want it located as close to your Dynamics 365 instance physically so that the latency for all communications between the portal and Dynamics 365 is as low as possible. With Microsoft managing the portal provisioning they take care of this for you. You still may want to determine the location for hosting of other services that will communicate with your portal, like when your looking at deploying a companion web app for your portal it would be ideal if it is the same data center as your portal.

You can quickly determine your major data center region just by looking at the address to your Dynamics 365 instance. The following link has a listing of all current major regions – Discover the URL for your organization using the Organization Service.  However within these major regions are regional data centers. For instance, https://*.crm.dynamics.com (North America which should actually be called USA/Mexico now since there is a region for Canada) has 3 different regional data centers and they are even creating secondary data centers regionally.  Within North America (or USA/Mexico) you could be in West US, Central US, East US, or even East US2.  Within CRM3 (Canada) you could be in Canada Central or Canada East as your primary data center. You can see all the Azure datacenter locations in the following link – Azure Datacenter locations.

Previous ways to determine your data center have involved spinning up an Azure VM and moving it through regions while doing latency tests.  You can also use a IP locator service to help you determine provided the IP address you testing has the proper location data registered with it (this sometimes can give false information as IP addresses can be re-routed to different regions).  Another way which the guys over at Peak Engagement blogged about is using the debug information page which reveals information about your Dynamics instance including the server name, database server, database name and much more.  If you look at patterns you may notice that the names of the servers are based on those regional data centers.

The Dynamics 365 portal has something similar but you can even use this technique on any Dynamics 365 portal without even being the owner of that site.  On every request response to the portal if you inspect the headers you will notice 2 additional response header keys added specifically for the Dynamics 365 portal, x-ms-portal-app and x-ms-request-id. The x-ms-request-id is just a unique GUID for each request, likely exposed to help assist with debugging. The x-ms-portal-app is a value for the site itself, it remains constant through all requests. Taking a look at the value found, there is the site GUID which is the GUID of the Azure Web App and then appended to that is a data center code.

You can easily get to this yourself without even being logged into the portal. The request headers are available on all requests. To look at this value open your browsers developer tools (F12), then select the network tab, open the details of any request and view the response headers. Below is a screenshot of Chrome’s developer tools highlighted with the navigation tips.

Below is a list of the data center region codes found on Dynamics 365 portals from the portals I have checked thus far.

  • EUw – West Europe
  • EUn – North Europe
  • USw – West US
  • GCv – US Government Cloud Virginia
  • GCi – US Government Cloud Iowa
  • USe2 – East US2
  • CAc – Canada Central
  • AUse – Australia Southeast

This is not an exhaustive list, if you come across others then feel free to drop a note in the comments.

You can now use this information to help you when picking a hosting location for a companion app as this region should be in same as your Dynamics 365 instance so you can attempt to get the best performance between applications and the backend Dynamics 365 instance.

Note there are instances where the Dynamics 365 instance and the portal will not be located in the same data center. This is not often the case but instances of this have seen that East US can host Dynamics 365 and East US2 can host the portal, this type of setup might also occur in other locations.

What is Adoxio Connect Framework for Dynamics 365 the Technical Details

For those of you who are interested in utilizing the Adoxio Connect Framework for Dynamics 365 in your own projects, be that a console application, Azure Function App, or an ASP.NET web app then this post will help you understand why we built this framework and the settings that it exposes. The goal of the Adoxio Connect Framework is to make it easy to use the new Dynamics 365 Server-to-Server authentication and help build applications based on this authentication schema without having to take on the management overhead of authentication.

When looking at the history of the Dynamics platform and how you built applications for it, you always had to do some sort of impersonation or maintain a service account of some sort. You could utilize a non-interactive user if you wanted to try to avoid taking up a license but this had a number of limitations with it and you actually still needed a user license to initially set it up. With Dynamics 365, Microsoft launched Server-to-Server authentication, or often referred to as S2S auth, that removes the previous need of a user account.

Developers over the last number of years have already been very used to this Server-to-Server type of authentication schema in that it was client credential or certificate based authentication and not user credential based. What that means is you have either a client ID and client secret or use client certificates as your credentials, you don’t need a user license at any step of the process. This is actually the proper way to authenticate an application as a service, like a portal or a scheduled process. Many mistake the Dynamics 365 Server-to-Server authentication as only for use with multi-tenant applications, meaning 1 code base or 1 service that accesses many different tenants, like AppSource applications, when in fact it can be used in multi-tenant as well as single tenant scenarios.

A really good example of a single tenant scenario is a portal or web app, and this is how the Dynamics 365 portal itself (or CRM portal if your still on the initial Microsoft release) does its authentication with the Dynamics instance (they use a slightly different version but the concepts are the same). A portal or web app is an application that runs as a service on a server, the users accessing the application are often not Dynamics users, they are external to the organization and it needs to basically be always on.

At present the Xrm tooling API library with the CrmServerClient does not easily support or provide the easy constructs to create a server-to-server auth based client. This is really due to the Active Directory Authentication Library (ADAL) and how it works in certain versions. As a result you need to do a lot of the figuring out and management of the ADAL yourself and requires you to really understand the concepts at play.

The Adoxio Connect Framework is meant to fill that gap in the Xrm tooling API and make using Server-to-Server authentication super easy, especially in a web app. You don’t have to worry about tokens, how to get them, attach them, etc., you just plug-in some settings and construct the context. The framework is not limited to only a web app, you can easily plug it into console applications, Azure Function Apps or any other .NET based applications. It allows you to construct a S2S auth based context, which we have called CrmContext (yes CRM, it is still CrmServiceClient 🙂 ) with a couple of settings and then you can utilize that context in various ways. CrmContext implements OrganizationWebProxyClient and then uses ADAL to get an Oauth bearer token and will attach it to the web proxy client. It figures out the hard bits for you, all you as a developer need to worry about is then using that context. To help make using it even easier the CrmContext also has an OrganizationServiceContext so that you can start using the Linq provider right away as well.

Part of making that easy is making sure you just have to add a couple of settings to the application. Those use to Adxstudio Portals development will know entering a connection string that consisted of an instance or organization URL, username and password. The Adoxio Connect Framework isn’t much different, it requires a resource (instance URL), client ID, client secret and the Azure AD tenant identifier. All of these can be stored in 2 different ways currently, either as appSettings in an application or web configuration file or as a settings.json. The framework contains a SettingManager to help assist with loading, validating and even saving the settings to they can persist through application restarts if you aren’t using a configuration file. Below is some example settings (they don’t actually work) of how you would put it in a configuration file.

<appSettings>
  <add key="dyn:SdkClientVersion" value="8.2" />
  <add key="dyn:ClientId" value="1d8925fd-8cbe-4f07-a83f-f59f7b111350" />
  <add key="dyn:ClientSecret" value="ckrtN4TrckIAF1i5ccEcJw+C4/ESfcyjWGBRBI80a3A=" />
  <add key="dyn:Resource" value="https://connectexampleinstance.crm.dynamics.com" />
  <add key="dyn:TenantId" value="ae83bd39-7849-4089-3965-1e5749dc4dc2" />
</appSettings>

You’ll also notice dyn:SdkClientVersion in that list. This one is optional, if you want to override the version of the SDK being used on the service endpoint and we haven’t updated the library to that version yet you can make that override yourself. If you don’t include the setting it will currently default to 8.2. The setting allows you to change the version in the following service endpoint URI:

{dyn:Resource}/xrmservices/2011/organization.svc/web?SdkClientVersion={dyn:SdkClientVersion}

At this point you might be asking how do I get a client ID and client secret and where the heck do I get my tenant ID from. This process could be a blog post of its own, which a couple of others have already done, as well as there is MSDN documentation on the process so I am going to refer you to them for the time being (let me know in the comments if you want to see this as a post).

The short is, you need to create an Azure AD application (so you’re going to need to be or need to get your Azure AD admin to assist you), this will giving you a client ID. Once you have an application you can define a client secret for it, and then assign the application permission to the Dynamics Online service. Within Azure AD you can also find your tenant ID. Once you have those you need to then create an Application User in Dynamics and assign it a non-default (not an out of box security role). Don’t copy the System Administrator role, for your sake and everyone’s create a proper security role restricted to the entities the service application actually needs. You will then need to consent or authorize the application. Once you have that process complete, your set, it never has to be done again for that organization instance.

It gets really simple now, you have either your appSettings defined or you have defined your own process to use the Save function in the SettingsManager to write a settings.json. You can now just use the default constructor of CrmContext and it will default to Load function in SettingManager which looks in both locations (appSettings first) and utilizes those in instantiating the OrganizationWebProxyClient in CrmContext.

using (var context = new CrmContext())
{
    var contacts = context.ServiceContext.CreateQuery("contact").Select(a => a.GetAttributeValue<string>("fullname"));

    foreach (var contact in contacts)
    {
        Console.WriteLine(contact);
    }
}

You’re done, you now have an IOrganizationService (OrganizationWebProxyClient) and an OrganizationServiceContext. You can make requests (Execute, Retrieve, RetrieveMultiple) and the full Linq provider (CreateQuery, UpdateObject, AddObject, etc.) at your disposal. If you want to use Xrm.Tooling, you can as well since CrmServiceClient has a constructor that takes OrganizationWebProxyClient as a parameter.

using (var context = new CrmContext())
{
	using (var serviceClient = new CrmServiceClient(context.WebProxyClient)
	{
		// insert CrmServiceClient calls
	}
}

Let’s talk about licensing for a quick bit here. We have made this open source using GNU LGPLv3. You should go read the details of that license but we have done this with good reason. I got asked this a lot at Extreme, “You guys are giving this away?! With the source code?!”. Yes, we want everyone to be successful with portals, as well as Dynamics and we think this is a little bit of help to kick start everyone with the new authentication schema. You’re free to fork or clone this repo into your own projects but LGPL also means if you enhance or modify this framework you too have to contribute it back and make it open source. You think you want another constructor or make some other addition to the framework? Make a pull request on the GitHub repo, we are all ears. Please contribute and collaborate with us as we want to grow and improve this framework, it’s going to benefit all of us.

How do you get it? The most current and all past versions will always be available on NuGet. You can easily put it in any project just by using the NuGet package manager, just search for Adoxio. Or by running the following from the NuGet Package Manager Console:

Install-Package Adoxio.Dynamics.Connect

The complete source code is published on the Adoxio GitHub if you want a look at the details.

Next post I will specifically discuss utilizing the CrmContext in an ASP.NET web app and you can see how easy it is to make it available everywhere in your web application.

Note: This post also appears on Adoxio Business Solutions Team Blog.

eXtreme365 Lisbon 2017 Highlights

Extreme365, the new ExtremeCRM has just completed in Lisbon, Portugal. What an amazing, beautiful and fun location to hold a great Dynamics conference. Lisbon was great, the food, historic locations, and the landscape were second to none. This event exceeded expectations with the quality of the sessions, the information shared by partners, MVPs and Microsoft themselves. I met so many smart Dynamics professionals and just really fun people to hang out with. It was an honor to be both an attendee to a great conference and a speaker. Big shout out to Nelson Lopes from Microsoft Canada for guiding us on an amazing Portuguese experience over the week.

So what was the hot news coming out of the event? A lot of great sessions from a number of partners as well as the Microsoft product group, here are some of the top things that caught my attention:

  • Virtual entities – allow data in external systems to be represented as CRM entities and can take advantage of Business Process capabilities. These are just models in the Dynamics system but no tables created in the database and no data is replicated. Plug-in to APIs and surface external data to Dynamics within the Dynamics interface. Have an Azure DocumentDB you want to show in Dynamics, or maybe some Salesforce data (😈), as long as it has an API or you can create your own you can surface the data and interact with it within Dynamics like its native Dynamics data. Important to note that there is no security model in Dynamics for virtual entities, security is the responsibility of the source system or API.
  • Flow and Logic Apps are major investment areas for the Dynamics product group. I think we can expect a lot of improvement to existing features and new functionality coming to these components, it is the workflow engine of the future.
  • Read only replicas across regions – if you’re a global organization then this one is for you. No longer will you have to deal with long latency to access to Dynamics data in another region. Coming in a future release will be the ability to replicate your Dynamics data to various regions but only in a read-only state, one region will remain as your primary with full read/write functionality.
  • 3rd party search functionality to allow a pluggable search provider instead of the relevance search that is powered by Azure.
  • Event Management – still coming and with an Event Management Portal! Organize events into sessions and tracks, manage schedules and conflicts, and track registrations.
  • On Premise Dynamics to need an Azure Pack in a future release to support items like a service bus and other functions so that closer parity between online and on premises can be maintained.
  • ALM for Dynamics – the cries for more robust Application Lifecycle Management tooling with Dynamics 365 have been heard and the platform team will be bringing PowerShell and API functions to provide better ALM functions for online. Exact details in terms of functionality are unknown as is the timeframe for this, but great news to hear — personally and from Adoxio’s perspective we really hope to see similar tooling to the ADX AlmToolkit and scripting capability for Configuration Data Manager so that it doesn’t have to be run interactively.
  • Custom controls like the Gantt chart in Project Service will be part of the solution architecture (they actually already are for PSA) in the next release so you as an partner or ISV can build your own controls and easily transport them just like other Dynamics components. Custom controls will be developed using standard web development technologies, JavaScript, CSS and image file assets.

For myself and Adoxio this was also a big event in that we launched both the Adoxio Connect Framework for Dynamics 365 as well as Adoxio Connect365. We were extremely excited to be able to do it at this event so we could share it with the Dynamics community and it has already been a great success. The Adoxio Connect Framework has been released as an open source library under GNU LGPLv3 so other partners are able to utilize the same core connection framework as we do to build our own products. We really want everyone to succeed with Dynamics 365 portals and we think the framework and the concepts we presented are a great way to help fill the functional gaps whatever they maybe for your implementation.

Adoxio Connect365 is our subscription based service built on top of the framework that has a number commonly requested extensions for the portals; modules available: SharePoint, Payment Services, ESRI and soon to come PowerBI. Connect365 can help you immediately add functionality that wasn’t possible before to your portals without having to invest, develop, maintain or even worrying about hosting and be supported by those that know portals the best. To learn more about Adoxio Connect Framework for Dynamics 365 and Adoxio Connect365 check out some of the links below. This is just the beginning, there will be so much more to come.

Thanks to the Extreme365 team for putting on incredible event, myself and the whole Adoxio team can’t wait till the next one!

Note: This post also appears on Adoxio Business Solutions Team Blog.