My first thoughts were Server Side Sync of course, but there was no reason for these appointments to be in Dynamics. Well, seconds later my reaction was. This should be easy enough using the Excel and Outlook connectors. I started testing a few scenarios and within about 30 minutes, we had a solution that was ready to test. What better solution then creating a Power Automate Flow.

I created a manual flow first just to test this logic, but after that modified this to a scheduled flow.

The first step was to create an Excel spreadsheet with the data elements that we needed. I created a spreadsheet and a table within the spreadsheet and called it EventsTable.

This table can naturally grow or shrink based on the data that is needed.

Next was to create the first action in the flow (after the Manual Trigger, which we later replaced with schedule). We used the List rows present in a table action using the Excel Online (Business) connector.

Specified the Location, Document Library, Filename and the name of the table.

The next thing is looping through all the rows of the table, and creating Events from these. I added an Apply to each control and added an Outlook 365 Create event (V4) action to create the event record inside of Outlook 365.

That is basically it. I ran the flow to test it out, and within seconds I could see the three events (calendar appointments within my Outlook Web App).

The only thing left to do is change the manual trigger. I just went ahead and deleted the manual trigger and added the Recurrence (Schedule) trigger, and set this to run on a daily basis.

We can add additional conditions to check if the event is already there or update the Excel spreadsheet to make that an event has been created, but will leave that for future requirements.

Thank you Cristian for asking how to get this done…

The post Creating Outlook Events from a OneDrive Excel spreadsheet appeared first on Aric Levin's Digital Transformation Blog.

In order to implement this logic, the first thing was to create the actual document in Microsoft Word. This document will be the template that we create, and will convert it to an Adobe PDF and finally Send it in an email message using Office 365. This process is based on a requirement to generate a license and send it as an email to the user when a new license is generated (or updated).

I found a sample template that I could customize in word. I designed the form, and at every place where I wanted Flow to insert a field, I created a Plain Text Content Control, and named it accordingly. The image below shows the completed design of the document in Microsoft Word.

After the document was generated, I uploaded the document to the SharePoint library to be used as a template. This is where flow will retrieve and generate the document from.

My flow starts with the Common Data Service (current environment) connector, using the Create or Update Trigger condition on the Licenses entity. I added an attribute on the Filtering Attributes, so that when the expiration date is modified, the flow will run and generate a new license and send it to the customer.

I then created a Parallel Branch to get the details from the Account and Contact records so that I can use that data in the generated email template, as this is a license that contains the information of the Customer and has individual contact details.

I also needed to get the details of the product record, so I added one more CDS action to Get a record on the Product entity.

In all of the last three actions that I used, I specified the Select Query details to only get the fields that I needed from CDS, as well as limit the amount of data that is visible in Dynamics Content. This makes it easier to find your data.

Now that I have all the data that I need to fill in the template, I will use the Populate a Microsoft Word template action to add all the data to the Word document.

The word document has three separate fields for the Print Date (Day, Month, Year), so I use the following function to display the partial date in each field:

convertTimeZone(utcnow(),’UTC’,’Eastern Standard Time’,'{FORMAT}’)

Since SharePoint does not have an PDF converter yet (or at least one that is free to use), I used the one that is available in OneDrive for Business to Create and Convert the file to PDF. First we will save the file in a OneDrive folder as shown in the image below, using the Create file on OneDrive action.

Next, we will convert the file to a pdf using the Convert file to PDF action. The only required parameters are the File Id from the previous step and the Target type which is PDF.

We can then store the generate file back into SharePoint (as a repository), but this step is not necessary. If we still want to do this, we will pass the SharePoint information, path, filename and the content of the file to save.

The next step is to Send the file. There are various ways to achieve this, and the easiest one is to call the Send an Email (V2) action, which will Send it from Office 365, as shown in the screenshot below.

I use the Email field from the Contact record, generate the subject and description with information from the license agreement, and use the OneDrive generated PDF and filename to add as an attachment.

Alternatively, if you would like to use the Email Entity in CDS and Server Side Sync to send the email, that is possible as well. You can get the Sender information from the Users entity (or if you have it in the license record even better). You then have to create an Email record with the details of the email, just as above. If you want to send the attachment with the email, you can create an attachment record and set the activity of the attachment record to the newly created email record.

You would then perform a bound action on the Email Message activity, selecting SendEmail as the Action name and passing the Item id of the email message.

When we run the entire process, we see that the Flow ran successfully.

A few seconds later, I open my Outlook, and will see that the message has been delivered to my Outlook, with an attachment associated with it.

If we open the attachment record, we will see the license with information and details populated within.

Additional information about the new CDS connector is available on the Microsoft Docs website.

https://docs.microsoft.com/en-us/connectors/commondataserviceforapps/

The post Generate Document Templates in CDS using Flow appeared first on Aric Levin's Digital Transformation Blog.

WIth the announcement of the October 2018 release of Microsoft Dynamics 365 (version number yet to be determined), which includes a mass number of features, one of the features that was included was management of SharePoint documents inside Dynamics portals.

This feature extends the document management capabilities of Dynamics 365 to portals, providing a consistent experience and allowing users to leverage their investment in SharePoint with Dynamics 365 for document management. Documents that are associated with entity records can be managed by portal users and stored in the SharePoint document library, providing seamless collaboration capabilities offered natively by SharePoint. SharePoint document libraries configured with entities in Dynamics 365 can be surfaced via the portal entity and web forms.

The additional of SharePoint documents for portals provides the following features:

• Adding documents to a SharePoint Library via Portals
• Viewing and downloading documents in a SharePoint Library via Portals
• Creating folders in a SharePoint Library via Portals
• Deleting documents in a SharePoint Library via Portals

The screenshot below shows adding a new file to the document library, a much cleaner interface than the existing Azure blob (notes) option.

Enjoy reading the new features that are available in the October 2018 release of Dynamics 365 available here. You can also download the 236 page pdf which contains the contents of the link and the features in this release.

The post SharePoint Documents are back in Dynamics Portals October 2018 Release appeared first on Aric Levin's Digital Transformation Blog.

There are a few custom entities which assist in the design of the layout of the subgrid, and well as javascript files that make up this logic.

The main different between this and the SharePoint grid is the ability to add additional attributes to the files that are being uploaded (as they are being uploaded).

The image below shows the subgrid that is displayed when the form loads. These documents have been uploaded from the subgrid web resource, and notice that the following attributes are also contained as part of the results: Account Name, Account Number and Document Type.

When uploading a new document, the application pops up a File Upload control with a picklist to select the document type that will be uploaded (as shown below).

When the document is uploaded, the Account Id, Account Number, Account Name and Document Type are set as attributes in the SharePoint folder. Also, all the documents that are pertaining to a single record within Dynamics, are uploaded to a single folder within SharePoint. The folders are Grouped by Entity Name and Entity Id, so that they are unique. The image below shows how the documents look in SharePoint after they are uploaded.

From the previous posts, the entire solution requires Configuration of SharePoint, Configuration of Azure, Development of the Web Api and the development of the HTML Web Resource. I am providing the source code of the entire implementation has been uploaded to my public github repository, and is available for download along with the CRM (Dynamics 365 v9) solution.

This is a customizable solution and requires certain configuration, so not really for the faint of heart.

Hope you enjoy this.

The post Dynamics 365 and SharePoint Online Integration – CRM Implementation appeared first on Aric Levin's Digital Transformation Blog.

If you haven’t developed any API projects with Visual Studio, I would suggest familiarizing yourself with Web API, and take a look at the following Microsoft Documentation: Getting Started with ASP.NET Web API 2 (C#).

The Web Api projects contains the following components which we will get into further details in this post:

• References to Microsoft.SharePoint.Client and Microsoft.SharePoint.Client.Runtime
• Reference to CAML Query Builder. This is a modified version of the CAML Query builder that is available on github: https://github.com/noormahdi/CAML-Query-Builder
• Controller classes for DocumentLibrary and LookupItems
• Model classes for LookupItem, SharePointDocument and SharePointFolder
• Helper classes for dealing with File Upload, Data, Encryption, and SharePoint

As the API library contains a lot of different functionality, I will go through the process of retrieving the documents API to show in the subgrid. The full source code and instruction on how to use will be available soon on github, so that you can implement this in your own environment. We will start by taking a look at one of the HttpGet methods in our Api Library. This is the starting point that the user will execute against the Api and get a response of the list of documents that are available on SharePoint.

[HttpGet]
[Route("api/Library/GetByMasterId/{id}")]
public HttpResponseMessage GetByMasterId([FromUri] string id)
{
	string authorizationString = DecodeAuthorizationString();
	SPHelper.SetSharePointCredentials(authorizationString);

	List<SharePointDocument> files = new List<SharePointDocument>();

	ListItemCollection list = SPHelper.GetDocumentsById(id);
	if (list != null && list.AreItemsAvailable)
	{
		foreach (ListItem item in list)
		{
			SharePointDocument file = ListItemToSharePointDocument(item);
			files.Add(file);
		}
	}

	var response = Request.CreateResponse(HttpStatusCode.OK);
	response.Content = new StringContent(JsonConvert.SerializeObject(files), Encoding.UTF8, "application/json");
	return response;
}

The function starts by Retrieving the Authorization Credentials. This is either passed by the Web Resource from CRM as an encoded string as part of the request, or in our case stored in the application setting. The function checks if the Request.Authorization.Header contains a value. If it does it retrieves the string from the Authorization header, or if not it creates the Authorization string from the Application Settings Username and Password.

private string DecodeAuthorizationString()
{
	string userPass = string.Empty;
	if (Request.Headers.Authorization == null)
	{
		// throw HttpResponseHelper.GetUnauthorizedResponseException("Auth Header is null!");
		string emailAddress = ConfigurationManager.AppSettings["Email"].ToString();
		string password = ConfigurationManager.AppSettings["Password"].ToString();
		userPass = string.Format("{0}:{1}", emailAddress, password);
	}
	else
	{
		var authHeader = Request.Headers.Authorization;
		if (authHeader.Scheme.ToLower() != Constants.AUTH_HEADER.BASIC)
		{
			throw HttpResponseHelper.GetUnauthorizedResponseException("Auth Header is not using BASIC scheme!");
		}
		var encodedUserPass = authHeader.Parameter;
		userPass = Encoding.UTF8.GetString(Convert.FromBase64String(encodedUserPass));
	}
	return userPass;
}

We then call the Set SharePoint Credentials function passing the Authorization string. This is using a Helper Class that handles with connectivity to SharePoint and executing SharePoint Client Commands against SharePoint.

public static void SetSharePointCredentials(string authorization)
{
	string[] authCredentials = authorization.Split(':');
	ServiceUserName = authCredentials[0].ToString();
	ServicePassword = authCredentials[1].ToString();
}

The GetDocumentsById connects to SharePoint (if not already connected), creates a CAML query with a where clause to search by the Master Id and returns a ListItemCollection.

public static ListItemCollection GetDocumentsById(string masterId)
{
	ClientContext ctx = ConnectToSharePoint();

	List spList = ctx.Web.Lists.GetByTitle("Documents");
	ctx.Load(spList);
	ctx.ExecuteQuery();

	if (spList != null && spList.ItemCount > 0)
	{
		string whereClause =  String.Format(@"<Where>
			<Eq><FieldRef Name='MasterId' /><Value Type='Text'>{0}</Value></Eq>
			</Where> ", masterId);

		CamlQuery camlQuery = new CamlQuery();
		camlQuery.ViewXml = String.Format(
		   @"<View Scope='RecursiveAll'>
			<Query> 
				{0}
			</Query> 
			 <ViewFields>
				<FieldRef Name='FileLeafRef' />
				<FieldRef Name='Title' />
				<FieldRef Name='MasterId' />
				<FieldRef Name='MasterNumber' />
				<FieldRef Name='MasterName' />
			<FieldRef Name='DocumentType' />
				<FieldRef Name='Created' />
			</ViewFields> 
	</View>", whereClause);

		ListItemCollection listItems = spList.GetItems(camlQuery);
		ctx.Load(listItems);
		ctx.ExecuteQuery();

		return listItems;
	}
	else
		return null;

}

We then loop through the items of the collection, and convert each ListItem to a SharePointDocument. SharePointDocument is a Model class that contains the fields that are returned from SharePoint, and will be returned to the web resource as a Json string. The function below shows the ListItemToSharePointDocument function which handles the conversion.

private SharePointDocument ListItemToSharePointDocument(ListItem item)
{
	SharePointDocument file = new SharePointDocument();
	file.FileId = (item["UniqueId"].ToString().ToGuid());
	file.MasterId = item["MasterId"] != null ? item["MasterId"].ToString() : "";
	file.MasterNumber = item["MasterNumber"] != null ? item["MasterNumber"].ToString() : "";
	file.DocumentType = FieldLookupValueToLookupItem(item["DocumentType"]);
	file.MasterName = item["MasterName"] != null ? item["MasterName"].ToString() : "";
	file.FileName = item["FileLeafRef"].ToString();
	file.FilePath = item["FileRef"].ToString();

	return file;
}

Finally, we create the response passing a Status of OK (regardless whether or not files were returned), and serialize the files object as a Json string and return the response.

The list of functions that are included as part of the Api are:

• GetByMasterId
• GetByMasterNumber
• GetByAlternateField
• DownloadFile
• UploadDocument
• SetFileAttributes
• DeleteFile
• GetRootFolders
• GetFolder
• CreateRootFolder

The next and final articles in this blog series will cover the creation of the web resource.

The post Dynamics 365 and SharePoint Online Integration – Web Api Development appeared first on Aric Levin's Digital Transformation Blog.

The first thing that we need to do is create an Application, so that we can register the Client Id for the new Application. In order to create an application. In your left hand navigation click on Azure Active Directory, and select App Registrations from the list of options. Click on New application registration button shown below.

In the Create window, enter a Name for the application, the Application Type (Native), and the Redirect Uri (not really used in this case), and then click on the Create button. Once the application is registered, you will be able to see its properties in the Registered App window. You will need the Application Id to store in the Client Id window. Next, we will need to provide the application permissions to the SharePoint server. Click on the Settings button in the Registered app Pane. This will open the Settings window.

From there click on the Required permissions under API ACCESS section. By default you will only have the Windows Azure Active Directory permissions. Click on the Add button to add additional permissions. We will need to add Office 365 SharePoint Online (Microsoft.SharePoint) permissions. Select Office 365 SharePoint Online, and check all the required permissions. At the least, you will need the following permissions:

Now that we have registered the App in Azure, we need to create an App Service with Azure. The type of App that we need to create is an Api app, which allow the connectivity between Azure and SharePoint.

In the Microsoft Azure navigation click on App Services. This will display the AppService navigation as shown in the following image. Click on the Add button.

In the Web Apps section shown below, click on the More button in order to see the selection for API App.

Click on the API App link, and then click on the Create button.

This will display the new API App window. Enter the name of the App, Subscription, Resource Group (either Add New or use an existing one) and the App Service Plan/Location. Click on Create button to finalize the Creation of the App. Once the app is created we will need to add some Application Settings to it as well as set up Cross-Origin Resource Sharing (CORS), which will allow Dynamics 365 code to execute the API functions.

In the Application Settings window, we will enter the following settings (as shown in the image and table below):

Finally, you will have to set up CORS, so that only CRM has access to this API. The screenshot below shows you the configuration of CORS. All that is required is the Url of the CORS

In the next article of the series, we will go over the Web Api, and uploading it to Azure.

The post Dynamics 365 and SharePoint Online Integration – Azure Configuration appeared first on Aric Levin's Digital Transformation Blog.

For our particular scenario, we create a Document Library called Document Center with a relative url of doccenter. In the root folder of the document center we created the following attributes (in addition to the default attributes):

MasterId, MasterNumber, MasterName, DocumentType

We also created 3 folders for ACCOUNTS, CASES and CONTACTS, though for the purpose of this series, we will only demonstrate the ACCOUNTS subgrid.

We also create a list called DocumentTypes which will be used by the DocumentType attribute to specify the type of document this is. No special configuration was done to the Document Type list, as we are using only the Title field.

We used the Master Id, Master Number and Master Name fields so that they can be used across the board for the various entities, however you can add additional fields or change them based on your requirements.

In the next section we will review how to configure the Microsoft Azure web site in order to have Azure connect to SharePoint.

The post Dynamics 365 and SharePoint Online Integration – SharePoint appeared first on Aric Levin's Digital Transformation Blog.

We ended up developing a solution that will solve some of this problems by using Azure API and the SharePoint Client Tools (can also be done with SharePoint API of course), and developing a custom web resource that will call the Azure API functions provide the ability to upload files to SharePoint as well as download files from SharePoint.

The image below shows the end result of the SharePoint Grid inside of a CRM entity.

I will provide a separate post for each of the following portions of the application is the next week (or so), as well as post a copy of the different portions of the Source Code on github.

This series will include the following articles:

• SharePoint Configuration
• Azure Web API Configuration
• API Library Review
• Web Resource Review

The post Dynamics 365 and SharePoint Online Integration – Overview appeared first on Aric Levin's Digital Transformation Blog.