I love Microsoft. Between their powerful technology and comprehensive support, I’m never left wanting for functionality or help. But with a legacy of great products as large as theirs—which includes upgrades, updates, and versions of most of their platforms and packages—it’s easy even for hardened Microsoft veterans to get lost in the verbiage and name changes. Microsoft Dynamics, and now the Microsoft Dynamics 365 family, are no exceptions.
Here we’ll look back at the history of Microsoft Dynamics and how the various components fit together to create what we now know as Microsoft Dynamics 365. Many of the versions were the result of Microsoft’s acquisitions of established companies and software—each with its own history—but we’ll limit ourselves to the Dynamics solutions as they arrived in the Microsoft world.

ERP & CRM

One more thing before discussing the versions themselves: most descriptions assume everyone understands what we mean by ERP and CRM. ERP stands for “Enterprise Resource Planning,” and CRM stands for “Customer Relationship Management.” An ERP-focused solution enables an organization to track and manage the progress of its business functions, such as manufacturing, delivery, and human resources. A CRM-focused solution helps an organization (typically of the sales-oriented variety) to track customer interactions from beginning to end of the process, from contacts to clients to closings.

Original Recipe: Microsoft Dynamics…

…NAV – In 2002, Microsoft acquired Navision A/S (where NAV comes from), a software company in Denmark. The name has changed a few times. Microsoft Dynamics NAV focuses on the ERP side of small and medium business, or local subsidiaries of larger international companies, offering management capabilities for things like finances, manufacturing, and supply chain.
…AX – Axapta (hence the “AX”) was a collaborative effort between IBM and Damgaard Data, a Danish software company that merged with Navision before that entity was acquired by Microsoft in 2002. Microsoft Dynamics AX is also an ERP-centric software suite, but targeted for enterprise-level, multinational business.
…GP – This was the first Dynamics product to bear the name—Dynamics 1.0—in 1993, developed by Great Plains Software. Microsoft bought the company in 2000 and kept the Dynamics name. Microsoft Dynamics GP shares a great deal in common with Microsoft Dynamics NAV as an ERP-centric suite, but offers more out-of-the-box functionality while sacrificing some customization capabilities.
…SL – Standing for Solomon, or Solomon Software, SL was acquired by Great Plains Software in 1999, and when GP themselves were acquired by Microsoft, the Solomon software went along for the ride. Microsoft Dynamics SL is another ERP solution with a focus on project-oriented businesses with functionalities like budgeting and forecasting.
…CRM – Microsoft developed Microsoft Dynamics CRM to focus specifically on sales- and marketing-oriented businesses, and launched the suite in 2003. More recently, Microsoft has cultivated the product’s customizability to make it applicable to an even wider range of business models.

Newest & Best

Microsoft has completely changed their pricing and packaging models. Businesses and organizations can now subscribe to Microsoft Dynamics 365 under one of a few plans, or take from the proverbial basket of Dynamics applications, a la carte. There are three plans at this time—Customer Engagement Plan, Unified Operations Plan, and Dynamics 365 Plan. The Customer Engagement Plan focused predominantly on functions formerly housed within CRM, and the Unified Operations Plan is tailored for large-scale ERP concerns. The Dynamics 365 Plan combines them both.

Conclusion

Don’t get lost in the name game. Customers now have the power to choose the functionalities that serve them best, and to add to those capabilities as their businesses grow. Microsoft continues offering the best business solutions around, and Microsoft Dynamics 365—between Business Central and Finances and Operations—leverages the best of all available worlds for your business operations.

Dynamics 365 provides amazingly powerful tools for tracking business processes step-by-step, initiating stage-dependent actions, and maintaining strong relationships with clients. Dynamics 365 even comes with a handy drag-and-drop interface for creating and changing Business Process Flows, allowing enormous control over a business’s moving parts. Like any program, this process-creating function places some boundaries on what can go into a process.

Five’s The Limit On Entities

A process sometimes requires or benefits from the use of more than one entity. However, a single process can only “span across” up to five entities, though they don’t necessarily need to relate to one another. Each stage in a process works with an entity type. So, for example, if a process contains ten stages, those stages can only pertain to a total of five entities. Perhaps 3 stages regard Account entities, 2 stages to Opportunity entities, 1 to the PhoneCall entity, 4 to AccountManager entities, and 1 more to a Lead entity. Be careful, too, because when attempting to create stages belonging to a sixth or more entity type, Dynamics won’t warn the user until they try to save, popping up with the message below. If a job requires more than 5 entities, it’s likely the design might benefit from being broken up into more focused processes.

Trying to save a Process Flow that addresses 6 or more entities will lead to this error screen.

Five’s The Limit On Decision Tree Depth… Kind of

During almost any process, decisions must be made and/or conditional events must be considered. “Is such-and-such allowed?” “Did they show up or not?” In designing a process in Dynamics 365, this is represented by adding a Condition component to the process map. Conditions can only resolve in two ways, a “positive” route and a “negative” route. As of now, there can only be five conditions in a given branch in any “positive” route. However, a process will support any number of conditions in “negative” routes. It’s a little confusing. If your process requires more than 5 conditions, you may need to break it up into more processes.

This is what happens when adding Conditions 1 through 5 to a Process Flow.

Here, there is no available slot appearing to accept a “Condition 6” component after Stage 6.

Notice the process mini-map in the lower left. Branches in the “negative” path from conditions will continue permitting more Condition components. But no more Condition components can be placed after stages at this point.

Some Conditions Apply… To Conditions

A Condition component must “ask a question” answered within the Data Steps of the Stage immediately preceding the Condition. Within a Condition, the Process creator can combine multiple AND or OR statements to create the rule, but the two operators cannot be used together. This means that a complex decision point in a Process—one requiring a combination of ANDs and ORs—will likely require some combination of multiple Condition components.

30 Stages, 30 Steps Each

There can be only 30 stages total in a single process. A lot can be accomplished in 30 stages, but the limitation is important to keep in mind. For reference, the out-of-the-box process, “Lead to Opportunity Sales Process,” has only four stages and twenty steps split between them. It would have to be a truly massive and complex process to come close to facing the 30-30 roof.

Dragging a stage onto the flow won’t be permitted if there are already 30 stages total within the process.

Dynamics won’t stop you from adding more than 30 steps to a stage, but it won’t let you save it, either.

I “forced” more stages into the process by adding Conditions, which can’t be left with two empty branches. When I tried to save the process, I got this error.

Conclusion

In all likelihood, only enormously complex edge cases will encounter the limitations of Business Process Flows in Dynamics 365. Dynamics 365 remains an incredibly useful tool for client-based operations.

Sometimes, two great tools need some help to work together. Microsoft Bookings is a relatively new appointment-booking app in Office 365 focused on small, appointment-oriented businesses. Dynamics 365 is Microsoft’s enterprise-level app focused on helping sales-oriented businesses create and track business relationships from leads to opportunities to clients. As of now, getting these two helpful technologies to share their schedules isn’t automatic or straightforward, but I’m here to help. Before continuing, know that you must have O365 Admin privileges in the target tenant in order to enact some of these changes.

Getting Dynamics to Talk to Exchange

First, lets get Dynamics 365 trading and tracking its calendar with Microsoft Exchange. In Dynamics, go to the Navigation Dropdown -> Settings -> Email Configuration.

In the Email Configuration options screen, go to Email Server Profiles.

Ensure that Microsoft Exchange Online is set as the default.

Back in the Email Configuration options screen, go to Email Configuration Settings.

Ensure the four options under the Email tab in “Configure default synchronization method” section are set like this. Then click OK.

Again on the Email Configuration options screen, select Mailboxes.

In order, select the desired mailbox(es), click on “Approve Email”, click on “Apply Default Email Settings”, and click on “Test & Enable Mailboxes.

Adding Dynamics 365 Access to Outlook

As of now, adding Dynamics support in Outlook is in preview status. In order to permit this, go again to the Navigation Dropdown in Dynamics, and from there to Settings, to Administration.

Click on System Settings.

Under the Previews tab, in the MailApp Preview section, set “Enable Dynamics 365 App for Outlook Preview” to Yes. Then click OK.

Back on the Administration options page, click on the settings gear in the top right corner, and then select Apps for Dynamics 365.

Under the Previews tab, in the MailApp Preview section, set “Enable Dynamics 365 App for Outlook Preview”* to Yes. Then click OK. (Pictured is the screen after confirmation and installation are complete. Installation can take several minutes.)

Once again, go to the Navigation Dropdown, then to settings, and to Dynamics 365 App for Outlook.

Select the desired target User(s), and then click Add App to Outlook.

What It Looks Like: Bookings to Dynamics

After the settings have been configured, try creating an appointment in Bookings through the customer interface.


The appointment will, of course, show up in Bookings’ calendar employee calendar interface.

It should also show up in the user’s Outlook calendar. In order to track it from within Dynamics, open the occurrence in Outlook.

Click on the Dynamics icon that now shows up at the top of the event window. Click on the option dots, beside “Not Tracked, and finally click on “Track without Regarding.”

After doing so, you should be able to confirm the scheduled time in Dynamics 365. Go to the Navigation Dropdown ->Sales -> Activities…

…and the appointment should show up in the list of Activities.

What It Looks Like: Dynamics to Bookings

Go to the trusty Navigation Dropdown, then to Sales and Calendar.

Create a new appointment on a future date.


You should see the appointment show up in the Outlook Calendar.

As of now, appointments made in Dynamics do not show up in the Bookings calendar…

…but when customers attempt to make an appointment through the Bookings app, the times scheduled in Dynamics will not be available as options.

Conclusion

Bookings and Dynamics offer incredible utility. For the time being, their different scopes means they don’t automatically share calendar and scheduling operations, but it’s still possible to reap the benefits of both apps with a little configuration.