Dynamics 365 Business Central Integration with Customer Engagement, Part II of II

This is the second in a series of blogposts devoted to Dynamics 365 Business Central. Specifically, it’s the second in two-part series on integrating Business Central with Dynamics 365 for Customer Engagement (CE). In the coming days and weeks, we’ll cover the integration with Microsoft Outlook and even some known issues and workarounds with that integration. In today’s post, we’ll finish our discussion on the integration between Dynamics 365 CE and Business Central.

Business Central Integration with Dynamics 365 for Customer Engagement

Login to Business central using your Integration user credentials:

Click on Search and type 365:

If you don’t see the Microsoft Dynamics 365 Connection Setup Page, you need to change the User Experience to Premium first.

Search for Company Information instead and click on it. Scroll down to the User Experience fast tab and change it to Premium. Refresh your browser and search once more for 365.

Click Microsoft Dynamics 365 Connection Setup > Assisted Setup.

Paste the Dynamics 365 for Sales URL and click Next.

The connection setup is to specify the user for the synchronization between the two services. Enter the integration user and click Finish.

The next window will prompt you to enter the admin user. Do so and click OK. The system will work on getting this connection ready. You can choose to map Salespeople at this point, or you can leave it for later.

Everything is set to this window; this is where we will see Dynamics 365 for CE URL, integration user, the active scheduled synchronization jobs, etc. Additionally, you can find some other important buttons in the toolbar, like Mapping and Synchronization. Before you go further, click Test Connection. You should receive a success message.

A few important notes about Mappings.

On the INTEGRATION TABLE MAPPINGS page, you can see the types of integration Synch. Job Queue Entries that are available. You cannot edit or create new. If you scroll to the right, you will see a column named SYNCH. ONLY COUPLED RECORDS, which matches data in both applications. In simple terms, if you have an Account in Dynamics 365 for Sales and the same Account exists in Dynamics 365 for Business Central, you probably want to couple them together to avoid having duplicates and mismatches.

When this box is checked, it means you want to couple/synchronize only those that are matched. In other words, if you have an Account in one application and not in the other, it won't synch because It synchs only coupled records.

In Synch. Job Queue Entries, if integrations are scheduled to be run, the status will change to Ready.

To the far right, there is a NO. OF MINUTES BETWEEN RUNS column, which you can change in two ways:

Go back to the INTEGRATION TABLE MAPPINGS page. Note that Contact and Customer are both directional. It means they can be sent and received in both applications.

Let’s start with customers first:

In the integration mapping for Customer, there is one condition:

The system will not take all accounts from CRM; instead, it will take only active ones with Relationship Type set to Customer. Additionally, if you want to create customers in Dynamics 365 for Business Central automatically, you can use Customer Templates:

For this blog, we’ll just go ahead and create a new one. Search for Set Up Customer/Vendor/Item Templates.

In this example, we open the Business-to-Business Customer (Bank) template and click New.

Press Esc and you can see the new one in the list:

Go back to the INTEGRATION TABLE MAPPINGS page in the TABLE CONFIG TEMPLATE CODE field, as shown:

Additionally, in this scenario, we don't have customers in both applications that we want to couple. Therefore, we uncheck the box, as shown:

Now, let's check what we have in both applications before we activate synchronization:

Check Dynamics 365 for CE > Accounts and Dynamics 365 for Business Central > Customer. Now Synch. Job Queue Entries:

Set It to Ready, wait for a few moments and check the JOB QUEUE LOG ENTRIES page:

If the job has run successfully, you can check the customer list again. You should be able to see new customers coming through.

There you have it! We hope this was helpful. Don’t forget to subscribe to our blog for more!

Happy Dynamics 365’ing!

D365 In Focus: Transform Your Organization with Sales Tool Belt [VIDEO]

In this Dynamics 365 In Focus video, Venkat walks through the Sales Tool Belt app created by PowerObjects. We love to create apps and add-ons based on customer feedback and functionality requests, and the Sales Tool Belt is no different! We created this app to give sales teams easier access to their CRM information while they are traveling. It has a host of useful and convenient features for those of you on the go. Watch this video to learn more!

Power BI URL Query in Dynamics 365 for Customer Engagement (CE)

In a previous blogpost, we discussed how to drill into Dynamics 365 CE records from Power BI. Well, how about the other way around – drilling from Dynamics 365 CE to Power BI Service? Today, we'll demonstrate how to display a Power BI report of a Dynamics 365 account in Power BI by clicking a link within a Dynamics 365 account form. Enjoy!

We are going to apply "URL Query" to achieve this feature by passing an account number from the Dynamics 365 account form to the URL.

The list below summarizes the steps:

Assumptions:

Let us get started!

Step 1: Create a Power BI Report with Dynamics 365 Data Source

We created a Power BI report to display a specific account information of Dynamics 365 for Sales. It includes Account Name, Account Number, All Opportunities associated to the account, Actual Value, Estimated Value, and Closed Date. The report is created in Power BI Desktop.

**The image below shows all opportunity data with no account selected

url query

Step 2: Publish the Report to Power BI Service

By clicking on the Publish button in the screenshot above, we have published the Power BI report from Power BI Desktop to Power BI Service. Once it is successful and the following message appears, click Open 'POC URL Query.pbix' in Power BI to view the report.

url query

Step 3: Create Two Fields in Dynamics 365 Account Form

We are going to use the Account Number field in the Account entity in Dynamics 365. We could achieve the same result by using the Account ID (GUID) field – however, one benefit of using Account Number is that it is a common field between Dynamics 365 CE and the Finance and Operations module. Therefore, we can use the Account Number field to associate between the two applications and create a data model in Power BI.

The Account Number field is available in the Account entity, although by default it is not displayed in the Account main form. Therefore, we need to add the field to the form. We will also create a custom field in the account form to store the "URL Query."

Adding Account Number field:

1. Login to Dynamics 365 for Sales and open an account form (for purposes of the demonstration, we are going to use the Proseware, Inc. sample account).

url query

2. Click on FORM as shown above. (Note that if you don't see FORM as an option, contact your System Admin for permission.)

3. The Account Form Designer appears. Click the Account Number field and drag-and-drop it under the Account Name field (labeled as 1 in the screenshot below).

url query

4. Click Save (2).

5. Click Publish (3).

6. Click Save and Close (4).

7. Refresh your browser to see the Account Number field in the form.

url query

Adding URL Query field:

1. Click FORM > New Field.

2. In the properties window, let's set the values as:

url query

3. Click Save and Close.

4. Refresh the web browser of the Account Form Designer (hit F5 key).

url query

5. Select Custom Fields from the Filter dropdown (labeled 1 in the screenshot above).

6. Drag-and-drop PBI Report under the Website field (2.)

7. Click Save (3).

8. Click Publish (4).

9. Click Save and Close (5).

10. Refresh your browser and see the PBI Report field in the form.

url query

Step 4: Create a URL Query

Next, we will extract and create a URL query string from Power BI Service. Let's open Notepad to save the URL for later use.

1. Go to Power BI Service and open the report page published way back in Steps 1 and 2.

2. If we have more than one page in the report, it is important to select the report page on which we plan to display by default.

3. Copy the URL and paste it into Notepad.
url query

In our case, this is what should be pasted into Notepad: https://app.powerbi.com/groups/me/reports/32068cc5-719a-46ba-8504-b78a62e8dc4a/ReportSection8b8acc8e442abc0c790a

4. Update the URL in Notepad by adding ?filter=accounts/accountnumber eq '' immediately following URL – with no space! Note that those are two single quotation marks at the end – not one double quotation mark. This is important, as you'll see in Step 5! It should now look like this:

https://app.powerbi.com/groups/me/reports/32068cc5-719a-46ba-8504-b78a62e8dc4a/ReportSection8b8acc8e442abc0c790a?filter=accounts/accountnumber eq ''

Step 5: Create a Workflow in Dynamics 365 to Populate Account Number in URL Query

1. Go to Settings > Processes in Dynamics 365.

2. Click +NEW to create a workflow.

3. In the properties window, let's set the values as:

url query

4. For Add Step, click Update Record.

5. Select Account for entity.

6. Click Set Properties.

7. Copy and paste the URL Query (from Step 4) to the PBI Report field (see below).

8. Under Operator > Look for, select Account and Account Number. Click Add, as shown:
url query
9. Before clicking OK, it is important to set the cursor between the single quotation marks of the URL Query and add the Account Number parameter between them. Account Number parameter = {Account Number(Account)}. The URL should now look like this:
https://app.powerbi.com/groups/me/reports/32068cc5-719a-46ba-8504-b78a62e8dc4a/ReportSection8b8acc8e442abc0c790a?filter=accounts/accountnumber eq '{Account Number(Account)}'
url query
url query

10. Click Save and Close.

11. Click Activate.

12. Click Save and Close on the workflow window.

Step 6: Let's See a Result!

First, we need to run the workflow we created in the previous step and populate the URL Query with account number for an account. Recall that we are using Proseware, Inc. for this demo.

1. In Dynamics 365 for Sales, open the account form of Proseware, Inc. Note that there is no URL Query created in the PBI Report field yet.

url query

2. Click on the ellipses next to PROCESS in the Command bar.

3. Click Run Workflow.

4. Select the workflow we created in Step 5 and click Add > OK.

url query

5. Let a few seconds pass and refresh the browser of the Proseware, Inc. account form.

url query

The URL Query link is populated!!! For other accounts, we can also run the same workflow from the All Accounts view by selecting all the accounts at the same time.

6. Let's click on the link in the PBI Report field.

7. The Power BI Service window appears with the account number filtered for the Proseware, Inc.

url query

 

We're done! This has been just one example of Power BI and Dynamics 365 integration by URL Query with no coding. It's slick.

Happy Power BI'ing & D365'ing!

Decommissioning a System Administrator

What happens when your Dynamics 365 for Customer Engagement system administrator decides to leave the company? Ugh, right? It's not something we like to think about, but it is certainly a very real business scenario. In today's post we'll walk through all the things that need to be considered, contemplated, and changed when this happens, as well as how to avoid these potential problems the next time your system admin jumps ship.

First, when this scenario does reveal its ugly head in your organization, which of the following should you do? (Hint: there's only one right answer.)

1. Panic.

2. Offer him/her a much higher salary to stay.

3. Disable his/her user record and just pretend everything is going to be ok.

4. Quickly, carefully, and efficiently analyze your system and make the necessary adjustments.

Hopefully, your answer is option 4 – after all, it's the right answer. (Well, unless you have an unlimited budget, in which case you may want to consider option 2.) So, let's get started on quickly, carefully, and efficiently analyzing the system and making necessary adjustments.

For Immediate Consideration

Most D365 for Customer Engagement system admins have a variety of roles within a company. They may be responsible for:

In other words, they very well may know the system inside and out and likely have their hands in just about everything. So, not only is the loss of their knowledge a potential challenge, but their login credentials may be tied to many various processes within your application. This means that disabling their user credentials or changing their password once they leave the company is likely to leave you with broken processes, errors, loss of functionality, and plenty of headaches.

But from a security perspective, they can't remain an active user either. So, once again… what can you do – specifically – to avoid those headaches? And no, enticing them to stay by doubling their paycheck still isn't the right answer. Instead, let's go step-by-step to ensure we keep your system up and running at full functionality.

Processes (Workflows and Business Process Flows)

Since workflows run in a user's context, we need to first reassign any workflows and business process flows that are owned by the former system admin. In Settings > Processes, find any activated processes that are owned by him/her and reassign them – ideally to the new system admin, but if that person is not identified or hired yet, reassign them in the interim either to someone with sufficient system privileges or to a Service Account (more on this later). Importantly, don't forget to reactivate each process afterwards.

Email

If your system has any automation in terms of sending emails, you must check whether any of those emails are being sent from your former system admin. If they exist in any To, Cc, or Bcc fields, that's ok – you can (if you choose to) leave them without causing future failures. Having said that, our recommended best practice is to remove them.

If they exist in the From field of any emails – typically created via workflow send email steps, it means all those emails will be sent in the context of that user's mailbox. Once the person if disabled from the system, those emails cannot be delivered. This is likely to occur when you have workflows designed to send notifications in the event of certain activities within Dynamics 365. For example, you may have a case assignment workflow that emails the new owner when they have been assigned a case – if you want that email to be sent and received, you'll need to change it so that the From field is an active user (more on this later).

Integrations

This is where it gets fun!

So, what if your departing system admin used his/her credentials to set up external connections into CRM? If so, you now know two things:

1. This admin was either doing a lackadaisical job or was focused strictly on guaranteeing job security – in either case, at least now you know for sure that you don't want to double that salary!

2. You have problems that need to be dealt with right away.

You must examine all of your external integrations, including:

Wherever necessary, update the credentials – preferably to a service account with the necessary rights. For example, if you have an active cloud-based PowerPack, such a PowerSurveyPlus, you will need to open the solution and update the username and password in the credentials area. (To learn how, scroll down to the Registration section on this page.)

Personal Views, Dashboards, and Other Records

This is not as critical as the previous items because a personal view or dashboard that has been shared to multiple people will not be affected if the original owner is disabled. However, unless Assign (or other rights beyond just Read) have also been shared, you may be stuck with these Views and Dashboards… forever! That's right, you'll never be able to change them. What that means is that if your departing system admin (let's call him Aaron) created a Contact View called Aaron's Team and shared it to others with read-only access, every person with whom he/she shared it will forever have this View – and because views are listed alphabetically, they'll suffer the added inconvenience of Aaron's Team showing up first forevermore!

Luckily, that's not exactly true. How do you make it go away? Use the magical REASSIGN RECORDS button (highlighted below) on the user record – it will reassign all records and views to someone else. Phew!

system administrator

The time it takes to complete reassignment will depend on a few different things, including the number of records to be reassigned and whether or not the reassignments cross business units (reassigning records leads to Dynamics 365 adjusting the record-sharing table in the background).

Disabling the User

The last step – disabling the user – is the easiest. You can do this from the Office 365 portal by simply removing the user's Customer Engagement license (alternatively, you can remove all security roles).

Preventing this in the Future

So, what's the biggest lesson learned here? "SERVICE ACCOUNTS!"

Need to see that again? Here it is, in more detail this time: "USE SERVICE ACCOUNTS!"

Here's what we mean:

In many Dynamics 365 for Customer Engagement deployments – and in all CRM on-premises environments – user logins are tied to an Active Directory user within the company (or you can also authenticate users directly within Office 365). In either scenario, you have the option to create non-user accounts. These are logins that only a handful of people in the company have access to and that are not tied to any particular individual. These logins have many different uses, and they can be configured to have full access to your Dynamics 365 application. There are different ways to reference this type of login, but for the purposes of this blog, we'll refer to it as a Service Account (recall that we mentioned these earlier and promised to get back to them).

So, if you have an activated workflow that does not need to be assigned to a specific individual, the best practice is to not assign yourself (or the developer) as the owner. Instead, assign it to a Service Account and activate it. And if you have a more complex setup where workflow owners belong to different business units, you can easily create a unique Service Account for each use case.

The end result of this approach? In the event that a system admin leaves your company, you can quickly and safely change the password of the Service Account(s) being used to run workflows – without impacting anything.

Note that it is also a must to always use a Service Account for any integration that connects to Dynamics 365 externally, such as SSIS, Scribe, Email router, etc. And we always recommend using a different account for each process, as doing so provides two clear benefits:

But what about auto emails? If you are sending email as an end user, do you have other options (again, we mentioned this earlier and promised to come back to it)? The answer is yes – you can send as a Queue instead, since a Queue can be configured as any email address and display name. Now, there are further considerations to take if you want to send as a Queue instead of an end user, and some of it may depend on your company's email policies and how your outgoing email delivery is configured. But if you have automation to send emails from your system based on records being created or updated, chances are you don't need to set the From field as an individual. In those cases, you will want to definitely consider using a Queue and possibly using a no-reply address … or even an e-mail that does not exist in your D365 Customer Engagement deployment. The bottom line is that you have options – and sending email as an end user is not always the best one.

So, there you have it… what to do when your system admin jumps ship and how to avoid the ensuing problems in the future. We hope this was helpful (and saves you some money and headaches in the process).

Don't forget to subscribe to our blog for more Dynamics 365 tips!

Happy Dynamics 365'ing!

Introducing PowerApproval: Approval Processes Built into Dynamics 365

PowerObjects is proud to announce the newest member of the PowerPack lineup – PowerApproval! This nifty add-on for Dynamics 365 for Customer Engagement gives users the power to build and run approval processes inside of their Dynamics system. Multi-step approval processes can be easily built and applied to any Dynamics record, and each approval step can be approved by a specific user, a team, the manager of the user who submitted the approval, or anyone else – it depends on your desired process.

powerapproval

The add-on is also easily extendable, so users can set up automated notifications, automated approval kick-off, and additional approval tracking by using Dynamics 365 workflows, charts, dashboards, and more.

As with all PowerObjects PowerPack add-ons, PowerApproval can be imported and tried, free, for 30 days. After you've had a chance to give the add-on a try, it can be purchased for $1/user/month. Visit the PowerApproval web page for additional details, and to get started!

Happy Dynamics 365'ing!