Monthly Archives: September 2017

Here is a question somebody asked in the community forums today:

I want to create a workflow that checks if a new lead is from a list of countries ‘List A’ (ie europe), then it will send an email to the team leader for those countries.  Then I will have a ‘List B’ (ie usa, canada etc) that will send an email to team leader for countries B.  Then List C and List D.

https://community.dynamics.com/crm/f/117/t/252513

Apparently, it can be done with some development.. but that made me thinking if it’s something I could do with TCS Tools ?

See below how it worked out.

First, I’ll need to emulate the same entity structure, so I’ll need to create a Country entity. Every country will have a name and a lookup to a country manager (which is a user in Dynamics). So, here how it looks like:

And I’ll have a couple of countries to make this a more interesting exercise:

The way I’m planning to make it work is:

• I will add a user lookup field to the Lead entity (will call it “Country Manager”, too)
• I will use TCS Tools to populate that field whenever lead’s “Country” field is updated
• And, finally, I’ll have a workflow that will be sending an email whenever that field on the lead is updated

 

Here is my new “Country Manager” field on the lead form – actually, I don’t need it to be on the form, but, for the time being, it will help with testing:

Again, that field is just a lookup to the user entity:

How do I populate that lookup without developing some custom code, though?

What I need is a FetchXml which will give me the country record based on the country name. So, let’s use Advanced Find to create the query:

I made sure I have added “countrymanager” attribute to the columns, and, then downloaded the fetch:

---

<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”>
<entity name=”tcs_country”>
<attribute name=”tcs_countryid” />
<attribute name=”tcs_name” />
<attribute name=”tcs_countrymanager” />
<attribute name=”createdon” />
<order attribute=”tcs_name” descending=”false” />
<filter type=”and”>
<condition attribute=”tcs_name” operator=”eq” value=”#address1_country#” />
</filter>
</entity>

---

Finally, I need to use TCS Tools with that fetchXml.

1. Let’s create a lookup configuration under TCS Tools:

 

The last screenshot is where all the logic is, really. Basically, what I’m doing there is creating a lookup configuration that will use tcs_countrymanager attribute from the fetch result to set tcs_countrymanager attribute on the record for which the workflow will be running (I’ll set up the workflow a bit down below). And it will use address1_country attribute of that record for the filter condition.

So.. Saving the record and starting to create a workflow:

Organization scope.. will run on create of the lead record and, also, on update of the “Address1: Country” field.

I need to add TCS Tools –> Attribute Setter step:

Configure the properties of that step:

Then activate the workflow.. And run a test.

Let’s create a lead and enter “Canada” into the “Country” field:

Click “Save” and observe the results (since it’s a real-time workflow that I created above):

As for sending the email – that can be implemented as a separate workflow or as part of the same workflow, but it’s going to be a very routine workflow (sending an email to the user that’s selected into the Country Manager field on the lead record), so, I guess, there is no need to show how to do it here.

Happy 365-ing!

I’ve been always wondering if editing a customizations file should be considered an “unsupported” customizations. That was sort of my gut feeling since, after all, that file is rather complex, and it’s not something you can edit easily – you have to go over a few steps to even get that file, and, then, you have to go over a few more steps to put it back to Dynamics:

• Create a solution
• Add all the necessary components to that solution
• Export the solution
• Unzip the file
• Find “customizations.xml” file in the folder
• Modify XML in that file
• Then package everything into a new zip file
• And import that file into Dynamics

 

That’s quite a few steps not to mention that the file itself looks rather complex if you’ve never seen it before. For example, there are over 11000 lines in the customizations.xml for the TCS Tools solution:

So, manually updating that file must be unsupported, right? After all, we are supposed to configure Dynamics using the “customizations” interface. That’s what I used to be thinking (but that’s not to say that I would never update customizations.xml manually, though. Even if I felt somewhat guilty every time I’d be doing that). And that’s until I ran into this article just a few days ago:

When to edit the customizations file

As it turned out, it’s not just supported.. There is a bunch of tasks that you may want to do directly in the customizations.xml. Some of them can be done through the user interface, some of them can be done using the SDK. But, if you wish to, you can make those changes directly in the customizations.xml:

• Editing the ribbon
• Editing the SiteMap
• Editing FormXml
• Editing saved queries

 

Actually, if you look at those 4 items, it kind of makes sense.

There are no SDK methods which you can use to update the Ribbon, yet you cannot do much about the Ribbon in the user interface. Of course there is Ribbon Workbench, but what it’s actually doing exactly that – it’s updating customizations.xml.

There are no SDK methods which would allow us to update FormXml either. More exactly, we can use SDK to update form records.. but we still have to use XML there. Or, alternatively, we can update customizations.xml, package the solution, and import it to Dynamics.

As for the save queries, that’s, probably, even more interesting. When building those queries in the user interface, we have to accept some limitations such as:

• Can’t use distinct=false
• Can’t use left-outer joins
• Can’t link the same entity more than one
• Etc

 

However, since FetchXml has support for all those feature (and it’s only a user-interface limitation that we can’t use them), we can still update those queries directly in the customizations.xml and import those changes to Dynamics.

This is not necessarily a game-changer, but it definitely makes me feel better keeping in mind that there is, probably, not a single Dynamics implementation where I would not make at least one of those changes in the customizations.xml (even if only to add a ribbon button using Ribbon Workbench)

Most of the times, if we wanted to add a button to the ribbon, we would create a solution, we would add an entity to the solution, and we would use Ribbon Workbench to configure entity ribbon in that solution.

It works great, but what if we wanted to add a button to all entity forms?

This is also possible, although, instead of the entity ribbon, we need to configure what’s called an application ribbon.

It’s exactly the same idea:

– Create a solution

– Instead of adding an entity, add “Application Ribbons” under the “Client Extensions”

– Save your solution

You don’t need to add any entities or other components to that solution – just load it to the Ribbon Workbench at this point.

Once in the Ribbon Workbench, you’ll have the same 3 ribbons (Home, SubGrid, and Form):

However, those ribbons will not be entity-specific. If you add a button to any of them, that button will be configured for the whole application.

Just make sure you have selected the right tab. For example, on the screenshot above I’ve highlighted Mscrm.Form.{!EntityLogicalName}.MainTab – use that tab if you want to add a button to entity forms. There are other tabs there which you can use to add buttons to the form designer etc.

Once you have added the button, simply publish the changes and have a look at the results.

Here is a Lead form:

Here is a contact form:

The same button will show up for all other “main” entity forms, even though I have not added it to any of the entity-specific ribbons.

Who is doing Waterfall projects these days? From my recent experience, it seems Waterfall has a bit of a stigma attached to it – almost everyone wants to go Agile. So, just in case, the image below might be a nice refresher of how Agile is different from Waterfall:

It came directly from this page: http://www.agilenutshell.com/agile_vs_waterfall

Problem is, what we often call Agile, is, sometimes, not quite as Agile.. I think Leon Tranter has really nailed it here: https://www.extremeuncertainty.com/most-common-reason-agile-fails/

We may call it Scrum, we may call it Agile.. But, in reality, it is, often, some sort of waterfall where we are trying to use Agile terminology to make it look like Agile, even though it’s really not.

And, I think, there are reasons for that because not every project can be delivered through a set of bi-weekly iterations. For example, I am just coming off a project that took me a few months to deliver, and, even though we started to share our builds with the users in the UAT environment long ago, it’s only now when that project is being released to production, and it’s only now when the real testing is happening.

Because it just would not make sense to have it in production before the product has reached certain level of maturity.

For example, consider these types of projects:

– An XRM implementation where an existing .NET application is to be replaced by a Dynamics solution
– An existing CRM system which needs to be replaced by Dynamics

In many cases, those projects are not, necessarily, “all or nothing” in terms of the feature set delivery, but they can come very close to it. How would you replace an existing CRM system with Dynamics unless you have migrated the data and unless you have covered all of the basic business processes in Dynamics? How would you move your users from a .NET application to Dynamics unless, again, they can do most of what they used to be able to do in Dynamics?

We need to do the data migration, we need to cover all of the basic functionality, we need to provide reporting.. Until that is done, all we can do is keep delivering incomplete versions of that new Dynamics solution to the UAT environment, but it’s not going to be easy to convince the users that they should actually spend any significant amount of time testing those versions since they will have to keep in mind all the limitations while running those tests.

Once the project is in production, though, it can, finally, become really “Agile”. First time it goes live, it will be missing some less important features, but that’s something we can work with in the Agile manner, finally. That’s when we can start doing iterations or sprints, and that’s when we can start deploying the updates in production in the end of each sprint.

On the other hand, consider a project where there used to be no CRM in the organization. It’s only natural, then, to start delivering CRM functionality through the iterative approach, which likely means Agile should work just fine on that type of project.

 

So, realistically, I think the answer to the question of which methodology we should choose on the Dynamics projects depends on a number of things, but, most importantly, it does not have to be a “one methodology fits all projects” type of answer. It does not even have to be the same methodology for the complete duration of the project. It can be Agile, it can be Waterfall, or it can be some mix/combination of those two.

What do you think?

A few days ago I wrote a blog post about word/excel templates:

http://www.itaintboring.com/dynamics-crm/wordexcel-templates-rock-in-dynamics/

And got a few interesting responses – it’s great to have readers who can point out something you don’t know.

One of the comments was that we can’t, really, control how related entities in Word Templates are retrieved. Come to think of it, that’s a really important drawback. For example, if I wanted to have a word template for the account entity just so I could see some information on the account itself, and, also, on the open opportunities associated with the account, I would not be able to control which opportunities would show up.

Have a look at the screenshots below. There is an account with 3 open opportunities:

There are, actually, 4 opportunities linked to the account. But one of them is a closed opportunity:

So, I created a very simple Word Template, and here is what I see there:

All 4 opportunities are displayed in the generated document.

Unfortunately, there is no way to define conditions and/or other query parameters (sorting, for example) for the related records when creating a Word Template.

But wait, what if I created a Retrieve Multiple plugin – would I be able to update those queries at “run time”?

As it turned out, Word Templates just ignore RetrieveMultiple plugins all together. Which actually means there are some other interesting implications:

• RetrieveMultiple plugins are sometimes used to implement localization labels – this won’t work
• RetrieveMultiple plugins are sometimes used to implement custom security – this won’t work
• RetrieveMultiple plugins are sometimes used to implement custom filtering – this won’t work

It’s easy to test – you might create a plugin using the code below:

public void Execute(IServiceProvider serviceProvider)
{
ITracingService tracingService =
(ITracingService)serviceProvider.GetService(typeof(ITracingService));
IPluginExecutionContext context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));

            IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

            throw new InvalidPluginExecutionException(“Test”);
}

All this plugin will do – it will throw an error. So, for example, with this plugin registered in the pre-operation for “RetrieveMultiple” on the Opportunity entity, I can’t load any opportunities view:

Which means I should not be able to create a document using my Word Template above.. And, yet, I can still create that document:

Interesting, isn’t it? Well, all we can do is keep this in mind for now – hopefully, there will be some workaround in the future versions.

PS. I dug a bit more and found an idea on the Dynamics ideas portal which Scott Durow submitted about a year ago, so, if you need this functionality, take a few minutes to upvote there:

https://ideas.dynamics.com/ideas/dynamics-crm/ID0000474

 

 

All the Dynamics projects I’m working on right now are still on 2013-2015 versions of Dynamics, and they are all on-prem implementations. This is because all of them are for different government departments here in Ottawa, and, somehow, 2016 version still has not arrived to this place.

So, all those fancy features available out of the box in the 2016/365 versions are just making me feel somewhat jealous of everyone who is enjoying them today. And the ability to use Word/Excel templates is definitely one of such features.

This post is not necessarily going to reveal some new features, but, at the very least, it’s going to put those Excel/Word template features in perspective so my fellow government consultants knew what they are missing.. and so that others knew how lucky they are 

1. If I had Word Templates, that would give me(and my CRM users) the ability to create summary/print forms easily.

As simple as that, but, without Word Templates, I have to rely on the SSRS reports for all those overviews/summaries, etc. And keep in mind it’s not just the ability to put entity fields into the document – it’s, also, the ability to use related entities, to create tables, and to use formulas in those tables.

Have you seen this page?

https://support.office.com/en-us/article/Use-a-formula-in-a-Word-or-Outlook-table-cbd0596e-ea8a-485e-a35d-b2cb2c4f3e27#__toc281293381

It’s talking about how to use formulas in Microsoft Word. Usually, we would be using formulas in Excel, but it’s also possible to do some of that in Word. We can use SUM(ABOVE) to get the sum of all cells above the current cell, or we can use SUM(LEFT) to get the some of all cells to the left of the current cell. We can even mix those in the formulas such as SUM(LEFT,ABOVE).

We can use mathematical functions, we can calculate averages, we can round the numbers, etc.

But that’s not all. Before there were Word Templates, it had always been a problem to generate the reports programmatically/in workflows. That is not a problem with Word Templates – there is an out of the box custom action for that:

Even if that custom action solves only half of the problem, it’s definitely the bigger half. We do need a custom workflow activity to extract note attachments after that, but it’s a routine development – no tricks are needed. If you are interested in more details, you can have a look at this post:

https://community.dynamics.com/crm/b/scaleablesolutionsblog/archive/2016/07/20/auto-generate-word-template-in-dynamics-crm-2016-and-attach-in-email

Either way, creating a word template like this does not take much time with Word Templates:

https://www.microsoft.com/en-us/dynamics/crm-customer-center/using-word-templates-in-dynamics-365.aspx

And, then, there are Excel Templates..

2. If I had Excel Templates, that would give me(and my CRM users) the ability to create nice excel reports easily.

Maybe you would argue that there have always been excel imports, dynamics spreadsheets, etc. It’s not the same, though. When there is an excel template, all users can be using the same template, so there is no problem of having multiple versions of the same excel spreadsheet without any synchronization between those versions. There is, also, no need to install Outlook client to ensure that Dynamics spreadsheet can connect to CRM. There is no need to set up a SQL data source either.. Users can just choose a view, choose a template, and they will get a nice dashboard like this one:

https://www.microsoft.com/en-us/dynamics/crm-customer-center/analyze-your-data-with-excel-templates.aspx

It’s almost like having an SSRS report.. although, it may, actually, be even better in many cases simply because it’s excel, after all.

Note: Right now I’m not sure if it’s possible to generate an excel file based on an excel template programmatically.

And if you are interested in more details on the personal templates vs system template, on the security settings etc, have a look at this post: https://community.dynamics.com/crm/b/crmandunifiedservicedesk/archive/2015/12/09/crm2016-template-management

It would be just awesome if we could use Excel/Word Templates on my current project where I had to develop a custom template engine that’s based on the usage of the rtf files  – that would save me a lot of time.

So, to wrap it up.. If you are still on the earlier versions of Dynamics for whatever reason, I think you should seriously reconsider your attitude There are other new features, but, even if you only got Excel/Word Templates as a result of the upgrade, it might well be worth the efforts.

 

A few days ago I was talking to a prospective client, and, once again, the question of how to approach custom development came up.

My immediate response was more along the lines of having as little custom development as possible on the Dynamics projects since, more often than not, those customizations are implemented by the consultants who come and go, and, once they are gone, there is very little knowledge left of how to tweak such customizations and how to maintain them. From that standpoint, it’s much easier for a non-developer to work with the “visual” design tools to configure workflows and business rules.

However, what struck me a little bit is that a few years ago I would have answered differently. It’s just that I’ve seen it on a few projects lately that a proper customizations governance strategy is rarely implemented once the project goes live. Come to think of it, it is not that surprising at all, since not every company will have an on-site developer to properly maintain the customizations.

But that made me thinking of something else.

Dynamics has been evolving quickly – we now have business rules, lots of out-of-the-box custom actions, real-time workflows, calculated fields, rollup fields. None of that was available not so long ago. However, all those new features, while being very useful, have limitations. Sometimes we know about those limitations when we are starting to work on a project, and sometimes we don’t. 

So we may think, for example, that we might use a calculated field to get the first day of the month based on the datetime value stored in a specific field. Or that we might start a workflow for a calculated field. Or that we might use some complex conditions for rollup calculations. But we can’t.

Look at it from the project management standpoint, though. You’ve collected the business requirements; you got an idea of what should be done first, and what should be done later; you’ve prepared the estimates, you’ve got a sign-off.. The team starts working on the project, and, then, you start discovering those technical limitations of the out-of-the-box functionality. For each of those discoveries, you will likely have to adjust the estimates, to renegotiate the requirements.. you may even have to re-design the whole solution at some point.

In other words, the main problem that comes with those limitations is that we do have some uncertainty. When there are limitations, you can never be certain that a specific requirement can be achieved using those out-of-the-box features.

Now what if you opted for the custom development? If you had chosen that route, you would probably have a lot of other problems – you would have to find the developers, you might have to train them, you might have to figure out how to manage the code.. But, with all that, you would likely have a very good and accurate idea of what’s possible, what’s not, and what it’s going to take to develop those javascripts/plugins.

Which is why if I had that conversation again, I would probably say that custom development on Dynamics projects still makes a lot of sense. It’s the most reliable and the most advanced customization technique that we can fall back on when everything else fails, and we should likely include certain amount of custom development, especially on the more complex tasks,  into all the  estimates and project plans.

 

Did you ever want to display a “loading” indicator in Dynamics? Like this one below?

For example, if you had a ribbon button that would be calling some kind of lengthy javascript, this kind of indicator would allow you to keep the users informed that Dynamics is still working on whatever it is that button is supposed to do.

That’s just one of the functions in the alert.js, though. There are others, but it’s all about displaying popup notifications in a user-friendly way.

You can download Alert.js solution for Dynamics from github:

https://github.com/PaulNieuwelaar/alertjs

And you can find complete documentation here:

https://github.com/PaulNieuwelaar/alertjs/wiki/Documentation

However, every now and then a question comes up in the Dynamics Community Forum where somebody would ask if alert.js is supported or not.

Paul Nieuwelaar (the author of Alert.js) wrote this:

“While technically unsupported, this code is 100% contained within the solution, and doesn’t depend on anything CRM related, so it’s unlikely this will break with CRM updates.”

It’s right there, on the alert.js github page.

But that’s what I wanted to elaborate on a bit more in this blog post.

In the Dynamics world, unsupported (when applied to the javascript customizations) means that the javascript is accessing DOM directly. That’s all about using the methods such as getElementById for example.

The problem with these methods is that you never know if they are going to work in the future versions of Dynamics since Microsoft gives no guarantee that there will be no changes in the underlying DOM model. All those html element id-s can change or even disappear, so, in that sense, this kind of scripts are not guaranteed to work after the upgrade.

However, in case with alert.js, it’s not accessing any of the Dynamics HTML controls directly. Probably the one and only “violation” you will notice in that alert.js javascript web resource is this:

Alert.$(“body”).append(alertJsHtml);

This is where an additional HTML element(containing some other elements) is added to the body of the document. The rest of alert.js will be using that dynamically created HTML to display the popups, to set the titles of those popups, etc.

The important part is: since alert.js is creating that HTML, it knows the structure of that html. Which means that, technically, alert.js script is not supposed to break anything even after Dynamics is updated.

Does it make it a supported customization? I would probably say so.. although, there is one scenario where it might break something.

It does not rely on the id-s or names of the Dynamics controls, it’s not trying to manipulate any of the default HTML. However, it’s adding its own HTML to the “body” of the document. Technically, if it ever happens that Dynamics internal javascripts do need HTML elements to be added in a specific order, this is where those scripts may break because of the alert.js. Even though alert.js itself is, probably, going to keep working.

In that sense, it’s probably correct to say that alert.js is, technically, unsupported. But, it seems, the likelihood of alert.js breaking something in Dynamics is very low, and those additional usability features it can bring to Dynamics may well be worth taking a bit of a risk:

 

This is not the most common development task by far, but that’s just one more reason to share the code since it took me a little while earlier today to assemble it from different sources.

Here is how you can upload all the files from the specified folder to Dynamics as web resources:

1. You’ll need to identify web resource type, so there will be a enum

        enum WEBRESOURCETYPE  
        {
            HTML = 1,
            CSS = 2,
            JS = 3,
            XML = 4,
            PNG = 5,
            JPG = 6,
            GIF = 7,
            XAP = 8,
            XSL = 9,
            ISO = 10
        }

2. You’ll need to be able to convert file contents to Base64

            static public string getEncodedFileContent(String pathToFile)
            {
                FileStream fs = new FileStream(pathToFile, FileMode.Open, FileAccess.Read);
                byte[] binaryData = new byte[fs.Length];
                long bytesRead = fs.Read(binaryData, 0, (int)fs.Length);
                fs.Close();
                return System.Convert.ToBase64String(binaryData, 0, binaryData.Length);
            }

3. And, finally, you’ll need to use all that to upload the files to Dynamics

        static void UploadWebResources(IOrganizationService service, string folder, string resourcesPath)
        {
            var files = System.IO.Directory.GetFiles(folder, “*”);
            foreach (var f in files)
            {
                string webResourceName = resourcesPath + System.IO.Path.GetFileName(f);
                var content = getEncodedFileContent(f);
                Entity wr = new Entity(“webresource”);
                wr[“content”] = content;
                wr[“displayname”] = f;
                wr[“description”] = “Uploaded File”;
                wr[“name”] = webResourceName;
                bool createWr = true;
                switch (System.IO.Path.GetExtension(f))
                {
                    case “.js”:
                        wr[“webresourcetype”] = new OptionSetValue((int)WEBRESOURCETYPE.JS);
                        break;
                    case “.gif”:
                        wr[“webresourcetype”] = new OptionSetValue((int)WEBRESOURCETYPE.GIF);
                        break;
                    case “.css”:
                        wr[“webresourcetype”] = new OptionSetValue((int)WEBRESOURCETYPE.CSS);
                        break;
                    case “.html”:
                        wr[“webresourcetype”] = new OptionSetValue((int)WEBRESOURCETYPE.HTML);
                        break;
                    default:
                        createWr = false;
                        break;
                }
                if (createWr)
                {
                    QueryByAttribute qba = new QueryByAttribute(“webresource”);
                    qba.ColumnSet = new ColumnSet(true);
                    qba.AddAttributeValue(“name”, webResourceName);
                    if (service.RetrieveMultiple(qba).Entities.FirstOrDefault() == null)
                    {
                        service.Create(wr);
                    }
                }
            }

The code above will start by loading the list of files from the folder identified by one of the parameters. Then it will create a new webresource record for each of the files, but it will also verify if the files has already been uploaded to Dynamics (in which case it will skip such a file.. but you might use “service.Update” if you wanted to update the web resource instead, just don’t forget to set wr.Id if that’s the case)

I think it’s the first time I’m writing a blog post about a feature that I can’t really try, at least not yet. Virtual Entities.. What could be the holy grail of integrations.. They are coming in the next release, so I can’t stop thinking of what this might mean for all the integrations we have to implement so often on the Dynamics projects?

There are a couple of posts that will give you a good idea of what to expect:

https://blogs.technet.microsoft.com/lystavlen/2017/09/08/virtual-entities/

https://community.dynamics.com/crm/b/crmpowerobjects/archive/2017/08/24/dynamics-365-july-2017-update-virtual-entities

In theory, it might be the end of integrations. If we could simply surface external data in Dynamics, this would mean we don’t really need to move that data back and forth between Dynamics and other sources.. we could just create a virtual entity and work with that data in Dynamics.

There is no argument implementing something like that would be a huge undertaking even for the Dynamics development team (although, it would be a killer feature), so.. how far have they got it this time?

I think there are a few major limitations:

• All data surfaced through the Virtual Entities is going to be read-only
• It seems all external data sources should support OData
• Dynamics security model is not applicable to the virtual entities
• We can’t register workflows/plugins on the virtual entities

 

Let’s imagine some scenarios..

1. We may want to display additional profile information normally stored in the external system on the contact forms in Dynamics

I’m not certain this is going to be possible for a couple of reasons:

• Somehow, we’ll need to create a quick view form for the virtual entity
• We will also need to create a lookup attribute in the contact entity that will be referencing that virtual entity

 

It seems this should be possible, though(see that powerobjects link above).

• 2. We may want to respond to the changes in the external data. For example.. What if account assets grow above a certain threshold where it’s supposed to become a VIP account?

 

That’s is going to be impossible since there is no way to register a workflow/plugin.

3. We may want to display some external assets associated with a contact record

It seems this is going to be possible using a subgrid(see that powerobjects link above).

Now, all of this would come at the cost.

We would have to explain to the users/stakeholders that all that data would be readonly. That would likely narrow the number of scenarios where we can really use this type of integration since, quite often, Dynamics is, actually, turned into a “master data source”.. so all the data updates are supposed to happen in Dynamics. In theory, we may still be able to support data updates using various web resources etc, but that would mean a lot of development.

Not all external data sources will be exposed through OData normally, so we may have to implement OData for those external services first. This will shift the focus from implementing the integrations in SSIS/Scribe to doing some extra development.. Keep in mind that ETL integrations have been around for quite a while – there are connectors for various data sources etc. More likely than not, similar OData connectors will start showing up for the same data sources, but, to start with, those OData web services will have to be hosted somewhere.

And, then, there is security. If we cannot control access to the virtual entity using Dynamics security roles, we will have to start implementing plugin-based security instead.

So, with all that said.. I’m still looking forward to the next release since I’m pretty sure there will be a few scenarios where virtual entities are going to represent the best integration option. Actually, they are going to be almost invaluable for the demo purposes.

However, it seems it’s still going to take a few more releases (at least) before we can actually forget about SSIS, Scribe, and other ETL tools. It’s just that we’ll have one more option now.