Some Important Difference in Dynamic 365

 Workflow categories

Dialogs are synchronous process and Workflows are asynchronous process.

We can develop custom workflow, but can’t customize dialogs.

There are four categories of processes you can choose from in when modeling your business practices:

• Workflow. Use this process to model and automate real world business processes. These processes can be configured to run in the background or in real time and can optionally require user input. Workflow processes can start automatically based on specified conditions or can be started manually by a user.
• Action. Use this process to create a new operation that is not available in a stock Microsoft Dynamics CRM installation or to combine multiple disparate operations into a single operation. For example, in the case of a support call center, you could combine create, assign, and setstate operations into a single new “escalate” operation.
• Business process flow. Use this process to create a visualization of the business process flow. Users are guided through various stages of the sales or customer service processes. At each stage, you complete specific steps and then move to the next stage. You can customize the process flow by adding or removing steps, changing the order stages, or adding new entities to the process flow.
• Dialog. Use this process to create an interactive step-by-step data entry form that requires user input to start and run to completion. When you start the dialog process, a wizard-like interface is presented so you can make appropriate selections or enter data as you progress through each page of the wizard.

Differences between Workflows and Dialogs

Workflows	Dialogs
Can be either started by a user or can be automated.	Must be started by a user.
Are asynchronous or real-time processes, and do not require user input to run to completion. Asynchronous processes run in the background while real-time processes run immediately.	Are real-time processes that require user input to run to completion. When you run these processes, a wizard-like interface is presented to you so you can make appropriate selections to run the processes.
The entity that stores the details about a running asynchronous workflow is AsyncOperation while a Process is used for a real-time workflow.	The entity that stores information generated by a running dialog is the ProcessSessionentity.
Triggers are supported for workflows. For a list of supported triggers, see Supported types, triggers, and entities for processes.	Triggers are not supported for dialogs.
Workflows that are created or updated outside of Microsoft Dynamics CRM by creating or updating the underlying XAML file are supported in Microsoft Dynamics CRM on-premises. For information about these custom XAML workflows, see Custom XAML workflows.	There is no support for created dialogs outside of Microsoft Dynamics CRM by defining XAML.

Workflows vs. Business Processes

Workflows	Business Processes
A sequence of tasks that processes a set of data or finish a task	The workflow, form, collected data, assignees, and all other parts that make a process flow
Are created by listing out steps and tasks	Must consider a much broader set of actors, data, reports, and business impact
Focuses on moving a task to completion	Focuses on achieving a key business goal
Tactical	Strategic

Differences between Dynamics 365 Workflows and Microsoft Flow

Microsoft Flow is now included with most Dynamics 365 plans. This means that when we start building background workflows for our Dynamics 365 instance we are greeted by the following message:

So, what is different when you build your Flow?

Triggers

First off, after logging in to Flow, and choosing Dynamics 365 as your connector you’re greeted with a selection of five triggers and template Flows you can easily adapt to suit your needs.

The five triggers are similar to but not identical to the options available in the classic Workflow designer:

The key differences here are the lack of “Record status changes” and “Record is assigned”. Both are easily replicated with the “When a record is updated” trigger in Flow, by selecting to update the Status or Owner fields of the records.

Actions

Now if we look at actions we can see that the actions available in the classic designer are the following:

 

In Flow we find the following actions for the Dynamics 365 connector:

These will cover Create Record, Update Record, and Change Status (using the Update Record action).

To start or stop a workflow we’d choose Flow management as a connector and select Start Flow from a lot of other options that may be quite useful depending on the situation:

Other Features

Another limitation is an inability to set the scope of the Microsoft Flow. In the classic workflow designer the process could be run at the User, Business Unit, Parent: Child Business Unit or Organization levels. In Microsoft Flow the scope of the process is always at an Organizational level.

Now to the availability to run. To run Microsoft Flows as child processes needs slightly more configuration but it is an option as detailed in this blog on building Nested Flows.

To run a Flow as an on-demand process is quite straight-forward as the new Unified Interface has put all Flows and Workflows in the handy Flow button in the ribbon:

 

Microsoft Flow Templates

An exciting difference between Microsoft Flow and Dynamics 365 workflows is the set of ever-growing templates. These templates allow you to easily adapt flows to suit your needs and browsing the templates may even spark inspiration to do things you never thought possible such as creating Leads based on Tweets or sending push notifications instead of emails when a lead is created.

Conclusion

There are currently some limitations in using Microsoft Flow with Dynamics 365 CRM, but for the most part Microsoft Flow is able to replicate most of the process that are being performed by workflows as well as providing exciting features that are not available through Dynamics 365 workflows.

Discovery service Vs Organization service

Discovery Service :
The IDiscoveryService Web service is used to determine the organizations that a user is a member of, and the endpoint address URL to access the IOrganizationService Web service for each of those organizations. This discovery service is necessary because Microsoft Dynamics CRM is a multi-tenant environment—a single Microsoft Dynamics CRM server can host multiple business organizations. By using the discovery Web service, your application can determine the endpoint address URL to access the target organization’s business data.

Organization Service
It is a primary web service that accesses data and metadata of an organization. This web service contains the methods that you use to write code that uses all the data and metadata in Microsoft Dynamics CRM.

Global Option set Vs Option set field

What is a Global Option Set?

Often referred to as “dropdown” or a “pick-list” option sets are a field type that can be created within Dynamics CRM.  An option set is a list of defined options that can be selected by a user to capture specific information, unlike a text field where the data can be “organic” or manually entered.

A “global” option set is functionally exactly the same as an option set, but after a global option set is created it can be reused in any entity as well as in any option set type field.

Creating a Global Option Set

Under Settings - Customizations - Customize the Solution - select the Option Sets Tab.

Select “Option Sets” from the left.

Selecting this will show a view of all the global option sets that have been created within the solution.

Click “New” in the top left corner to create a new option set.

Fill out the following fields

Display Name: This is a field that must be populated. This display name is what appears to the user when adding the option set to a field.  Note: Make sure to give option sets an identifiable display name to make it easier to find.  The Name field is automatically populated after the “Display Name” contains data. This is the schema name of the option set.

Selecting the “+” (plus sign) will add an “Item” option.

After clicking the “plus sign” the label will be “Item” rename this to the appropriate option name. Continue clicking “plus sign” until all the options needed are created.  The Value field is automatically populated after selecting the “plus sign”.

After all appropriate fields, options, labels are populated save and close the form and a global option set is created.

How to Add a Global Option Set to a Form           

This option set is not on any form yet. This option set must be added to the form.

Organization owned Vs User Owned entities

When we create a new entity in CRM, we have two option for “Ownership” as “User or Team” and “Organization”. Below are the main differences between these two types of entities.

OWNED ENTITY	USER/TEAM OWNED ENTITY
Entity doesn’t has Owner ID field. Hence, these entity records can’t be owned by any user/team.	Entity has owner ID field. Hence, it can be owned by user/team.
Entity records can be viewed by whole organization users	Entity records can be viewed by user based on their security roles
Records cannot be shared or assigned	Records can be share and assigned
Entity has only two security access levels as “None” and “Organization”	Entity has all access levels (None, user, BU, Parent: Child BUs, Org)

Fin Vs Advanced Find

FIND	ADVANCED FIND
Search is performed on defined attributes in Quick Find view	Search can be performed on any attributes, users can customize the attributes
Find searches only Active records in an entity	Advance Find searches in all records including inactive records
Fine filters on only one condition	User can declare multiple conditions dynamically in Advanced Find. User can define complex queries with GROUP AND & GROUP OR
Find gives better performance than Advanced Find	Less performance

Managed Solution Vs Unmanaged Solution



Unmanaged Solution
All solutions start out as Unmanaged. When it is in the unmanaged state, you can add, remove, update, and test any of the components of the solution. You can delete components of your unmanaged solutions, while leaving it available for use in the rest of the system. Some on the MS CRM dev team have likened this to your ‘source’ code of your system. The great thing about an Unmanaged Solution is that during development, you can create restrictions (like ‘not customizable’) on the components as they evolve.

Managed Solution
When your unmanaged solution is ready for the show, you simply export it to ‘Managed’. You could think of this as ‘compiling’ you code. You set the restrictions (i.e. prevent customizations on certain components) and the end user lives by those rules. But remember, they can still customize the components of the solution that are unrestricted. You cannot add or remove components of a solution, even if the component is unmanaged.
Once you have packaged the Managed Solution, it can be installed into another organization. They can also be deployed across multiple deployment types (Online, Partner Hosted, On-Premise) and all CRM Clients (web, Outlook, Mobile Express, and Offline via Outlook Client).

Append Vs AppendTo

‘Append’ and ‘Append To’ privileges works together in CRM. ‘Append To’ allows other entities to get attached with it. ‘Append’ privilege will allow the entity to attach the records of an entity which has ‘Append To’ privilege.

Ex:
Generally, we attach notes to an entity (Account). To do this Note should have “Append” privilege and Accounts should have “Append To” privileges.

Let say Entity1 and Entity2 has 1:N relation. Entity1 should have Append To and Entity2 should have Append permission to relate both the entities records with lookup.

Share Vs Assign




SHARE	ASSIGN
User who has share privileges on entity record can share to another user	User who has Assign privileges on entity record can share to another user
On sharing the record, selected permission given to new user on that record. Here, ownership of the record remain same.	On Assigning record, Ownership will be transferred to new user
We can use GrantAccess, ModifyAccess and RevokeAccess Messages to share the records with SDK

Please use oAuth2.0 authentication in Dynamics 365 / CDS – Console App

 If you are facing error while connecting Dynamics 365 from Console Application then use OAuth to connect using below code. update your code as per below.

using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;
using Microsoft.Xrm.Tooling.Connector;
using System;

namespace MFACRUDD365
{
    class Program
    {
        static void Main(string[] args)
        {
            string authType = "OAuth";
            string userName = "XXX@XXX.onmicrosoft.com";
            string password = "XXX@XXX";
            string url = "https://XXX.crm.dynamics.com";
            string appId = "51f81489-12ee-4a9e-aaae-a2591f45987d";
            string reDirectURI = "app://58145B91-0C36-4500-8554-080854F2AC97";
            string loginPrompt = "Auto";
            string ConnectionString = string.Format("AuthType = {0};Username = {1};Password = {2}; Url = {3}; AppId={4}; RedirectUri={5};LoginPrompt={6}",
                                                    authType,userName,password,url,appId,reDirectURI,loginPrompt);

            CrmServiceClient svc = new CrmServiceClient(ConnectionString);

            if (svc.IsReady)
            {
                PerformCRUD(svc);
            }
        }

        private static void PerformCRUD(CrmServiceClient svc)
        {
            //CREATE
            var myContact = new Entity("contact");
            myContact.Attributes["lastname"] = "Sample";
            myContact.Attributes["firstname"] = "Contact";
            Guid RecordID = svc.Create(myContact);
            Console.WriteLine("Contact created...");


            //RETRIEVE
            Console.WriteLine("Retrieving Contact...");
            Entity contact = svc.Retrieve("contact", RecordID, new ColumnSet("firstname", "lastname"));
            Console.WriteLine("Contact First Name:"+ contact["firstname"]);

            //UPDATE
            Console.WriteLine("Updating Contact...");
            Entity entContact = new Entity("contact");
            entContact.Id = RecordID;
            entContact.Attributes["lastname"] = "Sample New";
            svc.Update(entContact);
            Console.WriteLine("Contact updated");

            //DELETE
            Console.WriteLine("Contact Deleting");
            svc.Delete("contact", RecordID);
            Console.WriteLine("Contact Deleted");
            Console.ReadLine();
        }
    }
}

Understanding REST Headers and Parameters

Headers

The REST headers and parameters contain a wealth of information that can help you track down issues when you encounter them. HTTP Headers are an important part of the API request and response as they represent the meta-data associated with the API request and response. Headers carry information for:

1. Request and Response Body
2. Request Authorization
3. Response Caching 
4. Response Cookies

Other than the above categories HTTP headers also carry a lot of other information around HTTP connection types, proxies etc. Most of these headers are for management of connections between client, server and proxies and do not require explicit validation through testing.

Headers are mostly classified as request headers and response headers, know the major request and response headers. You will have to set the request headers when you are sending the request for testing an API and you will have to set the assertion against the response headers to ensure that right headers are being returned.

The headers that you will encounter the most during API testing are the following, you may need to set values for these or set assertions against these headers to ensure that they convey the right information and everything works fine in the API:

Authorization: Carries credentials containing the authentication information of the client for the resource being requested.

WWW-Authenticate: This is sent by the server if it needs a form of authentication before it can respond with the actual resource being requested. Often sent along with a response code of 401, which means ‘unauthorized’.

Accept-Charset: This is a header which is set with the request and tells the server about which character sets are acceptable by the client.

Content-Type:  Indicates the media type (text/html or text/JSON) of the response sent to the client by the server, this will help the client in processing the response body correctly.

Cache-Control: This is the cache policy defined by the server for this response, a cached response can be stored by the client and re-used till the time defined by the Cache-Control header.

Request headers

Table 1. Request headers

Header name	Description	Examples
Accept	Specifies the content types that are valid in the response message. If the server cannot respond with the requested content type, the 406 Not Acceptable HTTP status message is returned.	application/xml application/json
Content-Type	Indicates the content type that is used in the body of the request. The supported content type is XML.	application/xml
If-Match	Including If-Match in the header enables optimistic updating with ETag. The server checks to make sure that the entity version numbers match, then writes the entity and increments the version.	a8f34, or any string of characters that represents a specific version of the entity
If-None-Match	Including If-None-Match in the header enables optimistic reading of entities by using ETag. The server determines whether the ETag information matches when a GET request is processed. If the information matches, then the entity did not change since the last request. The server returns the HTTP status message 304 Not Modified and does not retrieve the entity. If there is not a match, the GET request is processed.	a8f34, or any string of characters that represents a specific version of the entity

Response headers

Table 2. REST response headers

Header name	Description	Example
Allow	Lists the allowed request types for the solution or entity. If an invalid request is received, the HTTP status message 405 Method not allowed is returned.	GET
Content-Type	The MIME type of the response content.	application/xml
ETag	An alphanumeric string that represents the entity version.	a8f34, or any string that represents a specific version of the entity
Status	The Status line in the HTTP response indicates whether the server responded to the request successfully, or if there was an error.	200 - OK indicates a successful response 405 - Method not allowed indicates an error

Response status codes

The REST response includes a status code that indicates whether the request was successful, and if not, the type of error that occurred.

Table 3. REST response status codes

Code	Description
200	OK: the request was successful.
201	Created: the request was successful, and one or more entities was created.
304	Not Modified: the entity was not updated, possibly because the ETag condition, such as If-Match or If-None-Match, stopped the request from completing.
400	Bad Request: the request was not properly formed and therefore was not successful.
404	Not Found: the URI path is incorrect, or communication with the server was unsuccessful.
405	Method Not Allowed: the syntax of the request does not match the request type. The Allow header provides more information about the supported types.
406	Not Acceptable: the Accept header response type is not supported. The supported types are XML and JSON.
409	Conflict: the entity or entities cannot be overwritten or deleted.
412	Precondition Failed: when the If-Match header is included in the request, this status indicates that the ETag information did not match and therefore the entity was not updated.
413	Request Too Large: the number of entities that is returned is too large.
415	Unsupported Media Type: the request contains a format that the server cannot interpret.
500	Internal Server Error: this status indicates that an error occurred on the server and it was unable to respond.
503	Service Not Available: the solution is not ready and could not respond to the request.