Category: Blog

Icon packs to match D365 CE UCI entities

Icon packs to match D365 CE UCI entities on

There are ton more on which you can pick from. Modify the SVG to be a shade of #999999 to get a good match on color, and pick from lineal designs aren’t too concentrated.

Filed under: Blog, Dynamics 365/CRM

Send data from WordPress (and other PHP sites) to Dynamics CRM/CE

On of the easiest ways to capture data from WordPress and other PHP based sites and send it to Dynamics CRM/365CE has to be the PHP Toolkit created by AlexaCRM. They have two tools available for use for free.

  1. PHP Toolkit
  2. WordPress Plugin

    WordPress Plugin for Dynamics CRM

    If you have a WordPress site, connecting to Dynamics CRM/D365CE is a 10-minute exercise. Install the WordPress plugin on your site, create a form in Dynamics with a distinct name, add a page in WordPress and put the following shortcode snippet in the code editor.

    Unexpected error: An exception has been thrown during the rendering of a template ("Authentication failed: AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app 'db75707e-ae4f-49aa-bc64-3306f4a65382'. Trace ID: 1be38705-30e4-40ad-9b89-22ea3f0b0f00 Correlation ID: 7fde15a1-6623-4389-93b2-a9c919b2c31c Timestamp: 2024-07-18 13:29:22Z") in "template_b04d9354c3b12a2bacb8b36ae5ef9855510e5525".

    In the code above, replace the “Contact Card” with the name of your form in CRM. That’s it!

    Other PHP based sites

    If you have any other PHP based site like Joomla or Drupal, you can use the PHP Toolkit to connect Dynamics CRM/365CE to your site. Put the toolkit libraries into a libraries folder and you can call them from any page since it’s PHP. AlexaCRM has made examples available on their GitHub page.

    Filed under: Blog, Dynamics 365/CRM, Tools

    Using CRM from an external website – part 4: Demo “Web API”

    Originally posted on 25 August 2015 by Bas van de Sande on

    Welcome to the next episode in the “Using CRM from an external website” series. In my last article, I described the Web API scenario. The Web API scenario is the first step in the journey and depends on Microsoft Infrasctrucure ( I need a .Net/Mono framework and an Internet Information like server).

    In this scenario I hook up a web page to a Web API controller. The model behind the controller is responsible for getting the data from the back end CRM. As the Web API controller and the model are running in a .NET context, we simply can use the Dynamics CRM object model to get and set the data from CRM.

    I Use javascript on the web page to make the REST calls. For data retrieval (Select and SelectList) I use a GET method. For Data manipulation (Insert, Update, Delete) I use a POST method. The javascript conducting the calls to the Web API controller are the bridge between the client side context and the server side context.


    In this article I’ll show you the main concepts on passing data from the client side context to the server side context and vice versa. For the sake of simplicity the model class is not conducting any operation towards CRM.


    The Web API scenario is based on the MVC principles. We work with a single controller or multiple controllers (to define the actions) and with a model or multiple models (containing the data).
    Using MVC we need to specify where our controllers can be found. This has to be done in a RouteTable.  In the RouteTable you can specify how your URL’s should look like.

    The RouteTable is specified in the global.asax file in the web project.



    The basis of the Web API scenario is the model. In the model we define how the data should look like. In my implementation I use the model in a fashion that I can pass the model outside the boundaries of the assembly and still keeping full control over the behaviour of the class. I specified public properties and internal methods.

    The public properties can be get and set by anyone. The internal methods can only be called within the context of the assembly (read: controller).

    The idea of using a model is to simplify the transport of data over the server side and client side context.



    The controller acts like a façade (gateway) between the client side and server side context. As you can see all functions are decorated with two attributes.

    • HttpPost / HttpGet
      This attribute defines in what context the function is called. By either a HttpGet or a HttpPost method.
    • ActionName
      This attribute defines the name of the function to the outside world. This way we can give meaningfull names to our get and post methods and we can have multiple get and post methods within the controller.

    To simplify communication between the server side and client side context, we try to work as much as possible with simple data types (like string etc), instead of using complex objects. However, when you look at e.g. the Insert() function, you see that we pass in a string representing a model.
    The model is deserialized and instantiated into our strong typed model class.

    Once instantiated we can call the appropriate method on the model to conduct the action we desire. On the other hand we can return complex objects back to the client side context by simply using the object.  The javascript JSON call handles all serialization and deserialization for us. *nifty*


    Javascript methods

    On the web page we have basically two kinds of methods. Either a GET or a POST method.

    Looking at the GET method, we simply specify the URL in the format defined in the RouteTable. We have to omit the word “Controller”, that is handled by MVC.

    Our url looks like:

    “api / [name of the model] / [method on the controller] / ?[parameter]”.

    Please note that method names and parameters are case sensitive. Once the data is retrieved, we simply can use the properties defined in the model (case sensitive)


    Looking at the POST method, we have to a a bit more work.
    First of all we have to fill a JSON object and stringify it (encode it for transport).
    Then we pass it to our url in a parameter. Our url is enriched with a string representing our model. In the controller we deserialize the string and turn it into a .NET object.


    This is in a nutshell all technology you need to integrate your CRM environment in your website. As I mentioned before, this is only the first step. In this example I trust on the security mechanisms offered by the .NET framework and the Microsoft infrastructure. My ultimate goal is to be able to integrate my CRM environment with a non Microsoft environment.

    Filed under: Blog

    Project Management Process Guidelines Flowchart

    Use these flowchart diagrams as a visual aid to help understand the project management methodology. The diagrams show parallel and interdependent processes, as well as project lifecycle relationships.

    Initiation Processes Flow

    Planning Processes Flow

    Executing Processes Flow

    Monitoring & Controlling Processes Flow

    Closing Processes Flow


    Filed under: Blog, Tools