Sonoma Partners Microsoft CRM and Salesforce Blog

It’s Official! We’re a Microsoft ISV Development Center

Today's blog post was written by Ariel Upton, Marketing Manager at Sonoma Partners.

This week our team is at the Microsoft Inspire Conference in Washington D.C., meeting with Microsoft leaders and learning more about what’s to come for Dynamics 365. One piece of exciting news coming out of the Capitol – we’ve been identified as one of the inaugural Microsoft ISV Development Centers due to our CRM specialization.

As a member of this prestigious program, we have access to Microsoft ISV and product teams to work through specific architectural considerations and complex client requirements. If you’re a new or existing Microsoft ISV, this means we have an even stronger set of resources to help you build your solution for Dynamics 365, or re-platform an existing solution onto the Microsoft Cloud.

“Microsoft selected Sonoma Partners as one of our launch ISV Development Center partners based on their strong technical expertise, and their ability to help ISVs get their solutions through the AppSource listing process. Any ISV building a Dynamics 365 integration around sales, marketing and service should definitely consider engaging a company like Sonoma Partners to get their solution to market as quickly as possible,” Pat Fitzhenry, Director, Microsoft ISV Development Centers.

We’re thrilled to receive this designation and are here to provide advisory services to help ISVs get their teams up to speed on how to build, support, and maintain a D365-based solution. Thank you to our partners at Microsoft for selecting us as an inaugural Microsoft ISV Development Center!

Topics: ISV for CRM Microsoft Dynamics 365

ISV Customer Success Story: Glance Integrates Cobrowse Solution with Dynamics 365

Today's blog post was written by Kayla Silverstein, Marketing Specialist at Sonoma Partners.

According to a recent Forrester report: “Companies increasingly leverage visual engagement – video, cobrowsing, screen sharing, and annotations – to cut through the customer conversation clutter to be better understood, and to connect emotionally.”

Glance Networks is a key player in the visual engagement space, offering a platform that helps cut through “conversation clutter.” By leveraging Glance’s interactive visual offerings, users can provide better service experiences and online interactions with their clients.

We worked closely with Glance Networks to integrate their cobrowsing solution with Dynamics 365. We sat down with the Glance team to learn a more about their interest in building their solution for the Dynamics 365 platform, what it was like working with Sonoma Partners, and the growing importance of enterprise CRM in their industry.

Glance_blog_image_test1

Why did you decide to integrate your solution with Dynamics 365?

Glance: We’ve worked with other CRM partners for years. We get a lot of opportunities from these partners, and our customers are happy with the tightly-integrated functionality. In discussions with many enterprise accounts, we’ve seen an increase in those who already have Dynamics, or are considering moving to Dynamics. Given the quality of these prospective users, it made sense to explore how we could integrate our cobrowse solution with Dynamics. We’ve had great success with other providers, and Microsoft was eager and excited to work with us.

Why did you choose Sonoma Partners?

Glance: We asked ourselves whether we should choose a partner who knows Glance really well but doesn’t know Dynamics, or do we go with a new partner who isn’t as familiar with Glance but is an expert in Microsoft’s CRM space. Ultimately, we decided that this partner would need to become an expert in the Glance platform anyway, so partnering with a firm that has Dynamics expertise was the key factor in our decision.

“We wanted to work with someone who had a great reputation in the Dynamics space, and choosing Sonoma Partners was the best decision we could have made. They were able to deliver on their promises with a great product, and we couldn’t be happier with the end result.”

Apart from the integration with the Dynamics service itself, we wanted to work with a partner who understands the process of listing in Microsoft AppSource, and the intricacies that follow. This was fundamental to our success with our other CRM providers, so we knew how important that would be in raising our profile among the customer base. Sonoma Partners offered the expertise we needed to get the job done and cross the finish line.

 

Are you looking for a partner who could help you get into AppExchange or AppSource and invest your solution in a market-leading CRM platform? We’d be happy to help.

Topics: ISV for CRM Microsoft Dynamics 365

Discount Approval Emails with Dynamics 365 and Microsoft Flow

Today's blog post was written by Bryson Engelen and Kevin Yamashita, Sales Engineers at Sonoma Partners.

If you’re looking to do simple approval emails, there are some really easy ways to move data from Dynamics CRM to Outlook that don’t require any code. It allows a manager to approve, for example, a 10% discount, all while on their phone or sitting at their desk without the need to jump into CRM.

Below, we’ll walk through the basics of creating an approval email that brings in data from Dynamics CRM.

If you need more detail, or something more sophisticated, we’ve got the tools and expertise to take things further. This is just a simple way to get started, and you can see a video of the output here.

First, you’ll need an environment to test this out. Please don’t attempt this for the first time in production. You can provision trials for all of these components. Note: If you request a tenant with Project Service Automation, there is already an Approval Entity you can use. If you provision a 30-day trial and check the box saying you don’t want it customized, PSA won’t be loaded in, and you’ll need to create an Approval Entity in CRM. Additionally, 30-day trials don’t come with Outlook, so you’ll need to sign up for a free Office 365 trial in the Admin section of your Microsoft portal.

  1. CRM configuration
    1. Create a custom "Approval" Entity
      1. At a minimum, include a lookup field that points back to your originating entity (usually an Opportunity). If this is a Regarding field, you will encounter some limitations if you want to do more complex items like providing a link in the email to the Opportunity in CRM.
      2. Ensure the Approval Entity is enabled for Business Process Flows and Change Tracking (you can do this in the Default Solution).
      3. Optionally, include fields for added flavor such as a User lookup for "Approver," a yes/no field for "Approved," or a multi-line text field for "Approver Comments." If there are pieces of dynamic data that you want to include in your approval request email (including the recipient), be sure to include fields for that data on your Approval Entity.
    2. Create a new business process flow
      1. The primary entity should be the originating entity (again, Opportunity in most cases). Include one or two initial stages to capture basic Opportunity information (Estimated Close Date, Estimated Revenue, etc.).
      2. Add a conditional stage to branch off to if an approval is necessary. Usually our condition is if the Discount Percentage exceeds 10%. Note that you must include the field from the originating entity you want your condition to consider in the stage right before this conditional, approval stage.
      3. Create an Approval stage; in it, select your Approval entity and any relevant fields. This will prompt users to create a new Approval record when this stage is reached in the Business Process Flow.
  1. Flow configuration
    1. Create a connection to CRM and to Outlook
      1. Navigate to the PowerApps website (https://powerapps.microsoft.com/en-us/) and sign in using the same credentials as Dynamics 365/Office 365. Go to the "Connections" section from the left navigation bar. Flow and PowerApps use the same underlying connection infrastructure, but this is only available from the PowerApps website, so you have to go there first.
      2. Create a new connection to "Dynamics 365."
      3. Create a new connection to "Office 365 Outlook."
    2. Create a new Flow
      1. Now navigate to the Flow website (https://flow.microsoft.com), sign in, click "My Flows" in the top navigation bar, and select "Create from Blank" from the upper right-hand corner of the screen.
      2. First, we need to determine our trigger for this Flow; for this scenario, we'll use the creation of a new Approval record. Search for "Dynamics 365" and select "Dynamics 365 - When a record is created." Select your D365 organization and your custom "Approval" entity.

        Bryson 1_750
        Now we need to configure a step to send an approval email: select "+ New Step," "Add an action," search for "Approval," and select "Office 365 Outlook - Send approval email." You can now define the details of that approval request email (recipient, subject, body, etc.). Note that you can enter in static values or you can pull dynamic values from the originating Approval record via the dynamic content sidebar on the right that appears when you click into a given field.

        Bryson 2_750
      3. Next, we'll add a conditional step based on the approval response. Select "+ New Step" and "Add a condition." On the left-hand side, click the condition's "Choose a value" field and select the "SelectedOption" value from the dynamic content sidebar. On the right-hand side, click the condition's "Choose a value" field and type in "Approve" (unless you opted to change the approval options in the previous step; if so, use whatever text value you opted for).
      4. Finally, in each branch of the condition we will write the approval response back to CRM. After this you could add additional steps if you wanted. Click "Add an action" under the IF YES branch, search for "Dynamics 365," and select "Dynamics 365 - Update a record." Like in the trigger step, select your D365 organization and the custom "Approval" entity. In the "Record identifier" field lookup the unique identifier of the Entity (either the “Activity” field or the Entity name - if you set the Entity up as an Activity, choose “Activity,” if non-Activity Entity, choose Entity name) and then set any other fields that you desire for that branch of the Flow (at a minimum, you'll want to update your Approval record's "Approval Status" field). ANY REQUIRED field on the Entity will need to have that field set in Flow, so for example, if the “Subject” field is required, just populate that field with the “Subject” option in the dynamic content list.

        Bryson 3_750
      5. To update the Status, you’ll need to update whatever Status field is on your Entity. Often, this is the “Approval Status” field, so under the IF YES branch, hit “Show Advanced options” and find the “Approval Status” field in the list. Here you will need to enter the numeric value of the “Approved” option set value, which will look something like 100000003 (you’ll need to delete the commas if you copy and paste this from CRM). From there, you can set up the IF NO branch by basically repeating steps v. and vi. under the IF NO branch, except in the “Approval Status” field you will want to enter whatever numeric value corresponds with your “Rejected” option set value, which is likely 100000002.

        Bryson 4_750
      6. Then hit Save Flow and Done (depending on how frequently you saved, it may be Update Flow).
      7. Now save your Flow and give it a test by creating a new Approval record in D365!

Bryson 5_750

A few last things we will mention. For ease of use, it might make sense to populate the “Description” field of your approval record in CRM with something that reads well in the email (like we have in the image above). Also, there are more complex things you can do with this, like adding a hyperlink in the email to jump to the record in CRM (which would require a custom Workflow Utility like the one Sonoma Partners can provide you), embedding mobile deep links, or writing a workflow to copy information from the Opportunity record to the Approval record so the email picks up on that data. We can provide details on those in another set of instructions, but for now you have the basics.

Topics: Microsoft Dynamics 365

Running Server Side Code from the Microsoft Portal (Online)

Today's blog post was written by Matt Dearing, Principal Developer at Sonoma Partners.

Executing server side code from the Microsoft Portal (online) has some limitations. By default CRUD plugins and asynchronous workflows can be triggered, however, if you want to add your own custom button to the portal and have it execute synchronous server side code, or if you have a liquid template where you want to execute some server side logic to determine what to render, a pattern we call "Web Service Plugins" will work.

When web resources became a part of the CRM platform (back in CRM 2011) we used a pattern we internally called "Web Service Plugins" to execute server side code. The basic idea was have an entity called prefix_webservice and make a "RetrieveMultiple" request to it with no instances persisted in CRM. The entity would have 2 fields: prefix_logicclass and prefix_data. We'd then have a plugin registered on post "RetrieveMultiple" of this entity that would look at the query's prefix_logicclass to determine what server side class to instantiate and execute, it would pass along the value in prefix_data, generally serialized JSON, to this logic class. The benefits included things like: bundling http calls, reuse of server side logic, avoiding timeouts (could batch calls from the client and make sure each could run in under 2 minutes), etc. Custom actions have replaced "Web Service Plugins" for us in CRM, but the portal does not allow direct access to executing custom actions. Luckily, we can leverage the "Web Service Plugins" pattern from the portal.

Take the following example where we will call a custom action "SomeAction" from the portal. There are a few parts we need to configure to make this happen. First the liquid template:

You'll notice this liquid template is executing fetch and writing out a result. The "Mime Type" of this template should be set to "application/json".

Next is javascript you would add to the portal to execute the liquid template:


It's a simple ajax call leveraging jquery. It is making a GET request (you could also POST) to the liquid template's web page (with a partial path of "SomeAction") passing a couple inputs and a "stopCache" value. The "stopCache" value helps to ensure the output of our liquid template won't be cached but will instead actually execute the fetch, therefore executing our plugin. When the result comes back a button could display, a grid could hide, a message could be alerted, etc.

Next is the Web Service Plugin that handles routing the request:


This plugin has a single plugin step registered for post of "RetrieveMultiple". The plugin starts by getting the prefix_logicclass and prefix_data from the query. It then dynamically instantiates the logic class by name (leveraging reflection) and calls a specific method (in this case "DoWork"). Next it JSON serializes the result for returning to the client that made the request. For this to work all of the logic classes need a common interface (in this case an abstract base class). As new logic classes are added no change needs to be made to the plugin class or the plugin steps.

Finally here is an example of a logic class:


This method executes a specific action named "prefix_SomeAction" and passes along input then returns the output. It could be made more generic to support many custom actions especially if they are using more generic string inputs and outputs that include json serialized data.

Although not as straight forward as being able to make CRM service calls directly from the portal or being able to write server side code, a pattern like the above does give us the ability to still execute logic to help extend our customer's portal implementations.

Topics: Microsoft Dynamics 365

Managing Multi-Domain Mailboxes in Dynamics 365

Today's blog post was written by Neil Erickson, Principal Developer at Sonoma Partners.

We often get asked about the viability of complex CRM scenarios. Below is one such scenario:

The customer had multiple instances of Exchange running in multiple domains. Dynamics CRM users existed as Active Directory users on the same domain, so both users existed as users within Dynamics CRM. One user was set up in the primary Exchange instance. The other user was set up as a mail contact with an email address outside the primary Exchange domain. We were asked if it were possible for both users to be email-enabled within CRM.

The first thing was to determine the sync method to use for the mail contact user, which was easy in this case: the preferred option in this case was for the user to use the Microsoft Dynamics for Outlook plugin to sync with CRM. From there, we followed these steps to test out the account.

Step 1: Creating the users

Primary Domain: sonomacrm1.local

Primary Exchange server: sonoma-crm1exch.sonomacrm1.local

CRM server: sonoma-crm1.sonomacrm1.local

Secondary Exchange domain (for mail contact user): sonomacrm2.local

First user: Control user

AD: SonomaTest1

Domain: sonomacrm1.local

Exchange Mailbox: SonomaTest1@sonomacrm1.local

CRM user: Sonoma Test 1

Second user: Mail contact user

AD: SonomaTest2

Domain: sonomacrm1.local

Mail contact user email address: SonomaTest3@sonomacrm2.local

CRM user: Sonoma Test 2

Step 2: Adding the users to CRM

Both users were added from their existing AD users using the New Multiple Users function. CRM correctly imported their information and email addresses.

Step 3: Setting up user's mailboxes in CRM

Both users Mailboxes had to have their email addresses verified, then approved. Once approved, both mailboxes were then activated in CRM to mark them as active mailboxes.

Step 4: Setting up the Microsoft Dynamics CRM for Outlook plugin

This step consisted of setting up the plugin for each user on separate client machines. Both connected without issue. The setup for the control user was straightforward. The caveat here was setting Outlook to the right mailbox login for the mail contact user. In this case, we connected it to SonomaTest3@sonomacrm2.local. So it attempts to connect, but it passes that password from the SonomaTest2 account. Correcting that is an easy but critical part of the setup. This is critical since SonomaTest2 will be used to authorize to the domain and to the CRM instance but not to Exchange.

Once they are connected properly to Exchange, configuring the CRM for Outlook plugin is as simple as plugging in the correct CRM organization URL.

Step 5: Testing out emails, appointments, and tracking

For testing, we developed scenarios that would work seamlessly in the control environment for SonomaTest1. These included:

  • Tracking an existing email in CRM from Outlook
  • Composing an email from the CRM dialog and tracking it
  • Composing an email from the CRM dialog and tracking it with a regarding field set
  • Tracking an existing Outlook appointment in CRM
  • Composing a new meeting request from the CRM dialog in Outlook, tracking it, and setting a regarding field.
  • Composing an email to a contact from within CRM

These all worked without incident in both the control environment and in the environment for the secondary domain. Monitoring SonomaTest3's external mailbox confirmed emails and appointments were being sent out.

Topics: Microsoft Dynamics 365

Create Dynamics 365 Plugins with VS Code and the .NET Core SDK

Today's blog post was written by Ian Moore, Senior Developer at Sonoma Partners.

All the buzz in the Microsoft development ecosystem in recent months has been about .NET Core. If you haven’t been able to keep up with all the new technology and terms, here is a quick recap:

  • .NET Framework – The version of .NET you know and love. It is installed at the operating system level and runs on Windows.
  • .NET Core – A new implementation and runtime of .NET that is cross-platform across Windows, Linux, and MacOS. Applications that target .NET Core include the necessary framework assemblies with the application.
  • Xamarin – A .NET implementation that runs on mobile devices with Android or iOS.
  • .NET Standard – This is specification of .NET APIs – things like System.Xml, System.Linq, etc. – that are available on a given .NET runtime. Code that is targeting .NET Standard can run on .NET Framework, .NET Core, and Xamarin.
  • NET Core – This is the latest version of the ASP.NET web application framework. It can run on both .NET Core and .NET Framework.
  • .NET Core SDK – This is a new, cross-platform, standalone SDK for .NET applications. It includes a new project file format, NuGet enhancements, and a command line tool that can build and run .NET projects. This SDK can build projects for .NET Core, .NET Standard, and .NET Framework.

Okay, not so quick after all – but there’s a lot of new and great things happening in the .NET world these days. What do these .NET Core developments mean for developers who work with Dynamics 365? Since the Dynamics SDK Assemblies are still built for .NET Framework, we can’t use them to build anything cross-platform. But we can use the new .NET Core tools to develop plugin assemblies and console apps that connect to Dynamics 365. With Visual Studio Code, a new text editor from Microsoft, we can do all the development we need without ever opening Visual Studio.

Here’s what you need to get started:

1. Install the .NET Core SDK from Microsoft - https://www.microsoft.com/net/core#windowscmd

2. Open a command prompt and run ‘dotnet’ to confirm the SDK command line tools were installed successfully.

3. Install Visual Studio Code - https://code.visualstudio.com/

4. Start Visual Studio Code and open the Extensions menu. Search for the ‘C#’ extension and install it.

With those installed, we can make a Dynamics 365 plugin project with a few simple steps.

1. Open VS Code and go to File -> Open Folder and choose a new folder for your plugin source code.

2. Open the VS Code Integrated Terminal from the View menu or using Ctrl+` . This terminal will be PowerShell or cmd depending on your VS Code settings. https://code.visualstudio.com/docs/editor/integrated-terminal

3. In the terminal, run dotnet new classlib to create a new Class Library project in your current directory.

Ian moore blog 1

4. The command places two files in your directory: a stub .cs class file, and a .csproj file named after your directory. Open the .csproj file in the editor.

5. If you have ever looked at a csproj file in Visual Studio before, you will immediately notice the new format is significantly smaller. However, we need to change the TargetFramework to .NET Framework 4.5.2 to match the Dynamics SDK.

Ian moore blog 2

6. Now we need to add the Dynamics SDK package from NuGet. In the terminal run dotnet add package Microsoft.CrmSdk.CoreAssemblies. You will see this command adds a PackageReference to your project file.

7. Run dotnet restore to resolve the package reference.

Ian moore blog 3

8. Rename the Class1.cs file to MyPlugin.cs and open the file in the editor. Try making a simple plugin and notice that you have full intellisense support.

Ian moore blog 4

Here is an example plugin I wrote:

Ian moore blog 5

9. Back in the terminal, run dotnet build to build the project. You will find the output DLL in the bin/Debug/net452 folder.

Ian moore blog 6

10. There is still one more step required before we can register the assembly in Dynamics 365. We need to give the assembly a strong name using the strong name tool (sn.exe).

11. If you have a strong name key file already, you can skip this step. Otherwise, search for “Developer Command Prompt for VS2015” in the Start Menu and create a new key file with the command sn -k [YourProject].snk.

Ian moore blog 7

12. Back in VS Code, add the following lines to your csproj file within the Project element:

<PropertyGroup>
    <SignAssembly>true</SignAssembly>
    <AssemblyOriginatorKeyFile>CorePlugins.snk</AssemblyOriginatorKeyFile>

</PropertyGroup>

13. Your assembly will now have a strong name. Run dotnet build again from the command line to rebuild your project.

14. Now you can register your DLL with Dynamics 365 through the Plugin Registration Tool

Ian moore blog 8

With these steps complete, you can continue to add new plugin types by adding .cs files and including them in the .csproj file. This is exciting news for Dynamics 365 developers - it allows you to have all the tools needed to build plugins with the fully configurable VS Code editor. While Visual Studio will continue to be the go-to development solution for Dynamics development, it is nice to have a new and reliable option moving forward.

Topics: Microsoft Dynamics 365

Dynamics 365 Demo Video: Power BI Query Accelerator

Today's video and blog post were created by Kristian Altuve, Business Analyst at Sonoma Partners.

Microsoft Power BI combines a collection of software services, apps, and connectors to turn your complex sources of data into a visual and interactive format. However, when connecting to Dynamics CRM, there is still a lot of data cleaning needed before it is in a user-friendly state to begin creating Dashboard components. Power BI Query Accelerator was designed by Sonoma Partners to get your Power BI environment set up in a fraction of the time! Check out the video below to learn more or go directly to our download page here.

Topics: Microsoft Dynamics 365

Handling a Project Curveball with Project Service Automation and MS Project

Today's blog post was written by Nick Costanzo, Principal Consultant at Sonoma Partners.

For the last several months, Dynamics 365 has allowed project managers to use the MS Project Add In to link project plans to Project Service Automation (PSA) and manage their projects. The instructions here walk you through how to install, configure, and manage your WBS in MS Project while syncing it back to the linked project record in PSA. This works great if all projects run smoothly and everything stays on track. But what if your client throws you a curveball and the project hits a delay? We’ve all dealt with this, and the broad impact it has on the project team, resource managers, and financial forecasts.

Today I am going to cover how to leverage MS Project and PSA to address these challenges.

If we manage each change correctly, we can avoid striking out when we are faced with that hot, stinky, cheddar pitch.

1. First, let's start with our baseline project plan to create the project record in PSA and link them up by going to the Project Service tab > Publish > New PSA Project:

Nick cos 1

2. We’ve also gotten our resources booked, so now let’s fast forward to the completion of our Discover phase and our planned kick-off of the Iteration 1 Define phase on 5/29:

Nick cos 2

3. Let’s take a snapshot of our booked resources for reference. You can see the detailed view from the Bookable Resource Booking (BRB) records related to the project, which I’ve added as a navigation tile to the project form. For simplicity, I’ve also filtered the records down to Alan, our PM, and the week of 5/29/17.  As you can see, it’s a bit challenging to summarize the data as there is a record for each day, and the duration is displayed in hours in the view, but minutes in the chart:

Nick cos 3

4. Alternatively, once you refresh the plan in MS Project, you can get a much nicer view by going to Resource Usage. As you can see, we had Alan booked for 40 hours this week:

Nick cos 4

5. Next we will simulate what would happen if the client hits a delay with the Iteration 1 Define phase, by moving this date out by 1 month to 6/29/17 in MS Project and publishing it to PSA. You could do this directly in PSA, but in order to do so, you would have to unlink the MS Project plan.

Nick cos 5

Pro tip, make sure your all of your MS Project tasks are scheduled with Fixed Work, by selecting all, then clicking on Information > Advanced > Task Type > Fixed Work, to avoid unnecessary BRB records remaining with the original baseline dates.

Nick cos 6

6. Now you can see that the Iteration 1 Define phase start date and all subsequent dates have been moved out in the PSA WBS:

Nick cos 7

7. However we also need to make sure that the associated resource bookings have been moved as well. You can see that the all of the BRB records for the project have been adjusted according to the new schedule from the Iteration 1 Define phase onward. Again this is more clearly displayed in the MS Project, Resource Usage view:

Nick cos 8

8. With that complete, you have successfully re-baselined your project! And by keeping your resources in sync with the new dates you gain the advantage of:

  • Giving project team resources an updated view of their project bookings
  • Avoiding extra work for resource managers to change these bookings, and also allow them to book these resources to other projects during the delay
  • Ensuring the financial forecast is accurate for your project

Simple as that, by fighting off those curveballs, you can stay in control of your project and keep everyone on track.  After all, it's a lot easier to lay down a bunch of singles than it is to hit a home run!

Topics: Microsoft Dynamics 365

Sonoma Partners at D365UG / CRMUG Summit Nashville

Today's blog post was written by Ariel Upton, Marketing Manager at Sonoma Partners.

As June arrives and summer begins to spread its welcoming arms, it may pain you to turn your attention to the fall and look ahead to October. But if you’re planning to attend the D365UG/CRMUG Summit Nashville, it’s time to take a brief pause from the BBQ to take advantage of early-bird pricing (valid until June 29th, 2017).

Summit is the leading live event for Dynamics 365 users, featuring user-produced education on how to maximize the use of Microsoft Dynamics 365 and CRM. If you and your team are undecided about attending this year’s events, here are four reasons you should add Summit to your fall conference calendar.

Crmug blog 1

1. Content to benefit your business and your personal development.

We’ve all been to an event where we walk away thinking, “Well that was fun, but I’m not sure I actually learned anything meaningful.” Unlike other product conferences, the folks planning Summit go to great lengths to build a schedule filled with topics that CRM users are interested in learning about. The concentrated learning paths for Microsoft Dynamics 365 and CRM users (based on both role and skill level) include sessions focused on individual role responsibilities, industry best practices, and broader business goals. At Summit, you can engage in a tailored learning experience that best suits your individual needs. Thus, you’re guaranteed to leave with inspired ideas and actionable items that you can immediately layer into your deployment.

2. Network and swap best practices with peers.

Only at Summit does every other attendee talk the same talk and walk the same walk as you. At Summit you have authentic opportunities to meet with Dynamics peers and create connections that last after the event comes to a close. This is the perfect environment for you to talk, grow, build, and share your experiences with D365 & CRM with other users. 

3. Learn from the experts to get the greatest ROI.

Learn best practices and real world use cases from Dynamics 365 experts and Microsoft MVPs. Engage with a network of professionals throughout the User Group for Dynamics 365 & CRM who can help you uncover the best way to configure and customize, while maximizing out-of-the-box capabilities. When you compare high-quality training experiences to Summit, the ROI is unmatched. You and your team will walk away with tangible lessons to improve your implementation.


“Summit training is 3 ½ days of learning and networking. The total cost of the trip equals 9 hours of billable time. Awesome bargain!” – Joni, IT Manager, past Summit attendee

4. Spend time with Sonoma Partners.

With the sunset on Convergence, it’s inspiring to see the Dynamics 365 & CRM community pivot their energy and full attention to Summit. With year-over-year attendance growth and more active involvement than ever, we’re proud to be part of a group of people dedicated to the product’s evolution and success. Sonoma Partners is committed to helping people maximize their investment of Dynamics 365 & CRM, and we’ll be active participants and sponsors of this year’s event. Check us out at booth 811.

Music City, and the future success of your CRM deployment, is calling. Stay tuned for more announcements on our involvement at Summit 2017 and register now to take advantage of early-bird pricing.

Topics: Microsoft Dynamics 365

Best Practices for Microsoft Security Settings: Append vs. Append To

Today's blog post was written by Jen Ford, Principal QA at Sonoma Partners.

I frequently forget the difference between these two security settings. When setting up security permissions for a particular entity, I have always set them to the same values as each other, as a best practice, “just in case.” These two values do not always need to be the same, so let’s discuss how to set them properly with a few examples.

Say I am on the Contact form. I have a lookup to Account, and I have a subgrid of related Cases on the form. How can I set up my Append and Append To privileges on the Contact, Account, and Case entities so that they make sense for someone to create a Contact and associate these records?

To correctly set the Account lookup on the Contact record, set ‘Append’ on the Contact, and ‘Append To’ on the Account.

To correctly associate Cases to the Contact on the subgrid, set ‘Append To’ on the Contact, and ‘Append’ on the Case.

In this case, we are setting both Append and Append To on the Contact, but it is to provide security to fulfill two different relationships with the Contact.

If I wanted to provide the user with access to set all lookups on the Contact, and to associate any related records, this is a general rule to help set security settings:

For 1:N relationships on the Contact entity, set APPEND TO on the Contact entity, and APPEND on the related entities.

For N:1 relationships on the Contact entity, set APPEND on the Contact entity, and APPEND TO on the related entities.

In terms of other security, here are other considerations that will minimize the amount of security errors you could receive when creating or updating records. Let’s return to our example of a Contact record, with a lookup to the Account, and a related subgrid of Cases:

Do not set the APPEND TO level on the Account to be lower than the READ privilege of the Account. If you do this, then you will be able to select an Account you do not have access to APPEND TO a Contact, and get a security error.

Do not set the WRITE level on the Contact to be higher than the APPEND privilege of the Contact. If you do this, then you will be able to set an Account on the Contact that you may not have access to APPEND, and you will get a security error (this also depends on the READ level of the Account entity).

The same would hold true for associating a Case to a Contact:

Do not set the APPEND TO level on the Contact to be higher than the READ privilege of the Contact. If you do this, then you will be able to select a Contact you do not have access to APPEND TO a Case, and you will get a security error.

Do not set the WRITE level on the Case to be higher than the APPEND privilege of the Case. If you do this, then you will be able to set a Contact on the Case that you may not have access to APPEND, and you will get a security error (this also depends on the READ level of the Contact entity).

This is intended to be a starting point. There are always situations unique to customers that may need to set their permissions in a slightly different way. For example, Activities require both APPEND and APPEND TO to be set, in order to successfully create the records and associate them to other entities. As always, thoroughly test your security roles to ensure they are fully functioning.

Topics: Microsoft Dynamics 365