Podcasts about common data service cds

See how Microsoft Dynamics 365 Commerce supports you in the execution of your digital sales strategy with unified, intelligent, and personalized customer shopping experiences. This includes streamlining your existing supply chain and adding more resiliency. We'll show you how Dynamics 365 Commerce provides a unified experience between your organization and your customers, how it enables centralized operations, and what it takes to set it up. As a modern solution, Microsoft Dynamics 365 Commerce: • Shows intelligent product recommendations when customers visit your eCommerce site. • Gives customers a personalized experience by accessing their purchase history, shipping information, feedback, ratings and reviews. • Integrates with Dynamics 365 Fraud Protection, allowing you to run risk diagnostic reports and implement rules that leverage Microsoft's adaptive AI to react to fraud. • Comes with powerful analytics that allow your business users to review purchasing patterns across online and in-store purchases and see how specific locations are performing. Vanessa Fournier, Dynamics 365 Group Product Manager, shows you how Dynamics 365 Commerce enables intelligent and personalized interactions across your sales channels, all while protecting against fraud and ensuring increased resiliency. ► QUICK LINKS: 00:00 - Introduction 01:53 - Components that make it possible: ERP system & Common Data Service (CDS) 02:50 - Core components: Commerce HQ & API Integration 03:23 - Key channels: Online, Point of sale, & Call center 04:26 - Leverage Customer Insights 05:00 - Your eCommerce website 06:11 - Point of Sale (POS) experiences 08:12 - Drive down costs with Fraud Protection ► Link References: For a deeper dive on the Power Platform, and to learn more about adopting specific Dynamics 365 applications and services, check out our Dynamics 365 Essentials for IT series at https://aka.ms/Dynamics365ForIT. Learn more about Customer Insights at https://aka.ms/MechanicsCustomerInsights. Unfamiliar with Microsoft Mechanics? We are Microsoft’s official video series for IT. You can watch and share valuable content and demos of current and upcoming tech from the people who build it at #Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries?sub_confirmation=1 Follow us on Twitter: https://twitter.com/MSFTMechanics Follow us on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Follow us on Facebook: https://facebook.com/microsoftmechanics/

The Power Platform is on fire! Lot's of partners, developers and citizens are all creating all kinds of things at a rapid pace, it all seems so easy. Unfortunately many of them will get down the road and realize they should have taken a fork a few miles back. Let's see if we can map out the right path from the jump. Whatcha gonna do? Before thinking about where to start, you should have clear idea of where you want to end up. Depending on the problem you are trying to solve, some choices will become obvious. If you are just looking to be notified when a new file is uploaded to a SharePoint folder? Microsoft Flow is probably all you need. Not much "Architecting" required. For this post, I want to talk about bigger things you may want to do, like building a robust sales application for your team for example, or any other function for that matter. Sure, for my Sales example, the Dynamics 365 Enterprise Sales application is one option to consider, but again, here I will go for the Platform approach. Foundation Canvas apps are great for point solutions, Power BI doesn't do anything without data and Microsoft Flow is great for connecting existing things, but for most customers we recommend starting with a model-driven app on CDS. It's not the app that is the foundation, it's the Common Data Service (CDS). CDS is the heart of all things to come, and allows for everything you start to do now, to have a full future later. The App The model-driven app you will be provided with by default is fairly scant. It does include Accounts and Contacts as a common starting point for most business applications, although for a B2C scenario you may not even need Accounts. It is a nice "rolodex" at this point, but way more powerful in it's potential. From here you can "model" your data and processes that are required to solve your initial needs. To shorten this process significantly you may want to look at our RapidStart Accelerator Applications on AppSource. Regardless of your starting point, you will likely need some further development by yourself or a Microsoft Partner who specializes in Business Applications. The good news is, the effort required is significantly less than it has ever been before. Apps As you work on your model-driven CDS environment, you may see a need for more than one use case. Maybe your sales department needs something, but you also want something for the warehouse, or whatever. By the way I am just using "Sales" as an easy-to-grasp concept, but the app(s) could be for any business need. You have a decision to make with potential monetary consequences. Do you build two separate apps, or one and control access with security roles? Microsoft is launching a per/app/user license that is only $10, and it would be awesome to utilize just that. If your users are pretty segregated, and few or none of them  would have need to access both apps, you are fine. But if many of them need to access both, it will cost $10 X 2 apps. If many have to access 3 apps, it would be $30 for them. This maxes out at $40 for that 4th app as you would buy the unlimited app licenses at that point for $40/user. Still a bargain compared to past costs and other platforms. Architecting for License Cost As I said you could consider building a single app for all the different users needs and controlling who sees what, with security roles. It is more complex way to approach it, and could get unwieldy if you have many unrelated use cases, so you would have to weigh the costs of doing it that way vs. effort to make it that way. Again, this would only apply to users who wear multiple hats. Next Steps Let's say you now have a nice model-driven business application. Notice I did not say "basic", that's because it can actually be as complex and advanced as you need it to be over time. Are you done? Not even close. Now is when some of those other tools come into play on top of the foundation you have built. You have several options to go to next, one that is already covered in your $10 is a Canvas App, but this canvas app will take advantage of the CDS database you already built your model-driven app on, so all of that data is available. Also, Microsoft Flow, Power BI and Portals can be bolted on as well. So let's take a look at what these can add to your ultimate application to change the world, or at least your organization's world. Canvas Apps Canvas Apps are Task-Specific. The name Canvas comes from the design surface that you build them on, it looks a lot like PowerPoint. It is primarily a mobile application for those types of tasks that would be logically done on a mobile device. For example, adding a barcode scanner and tracking inventory in a warehouse, or a Check-in/Check-out app for corporate laptops. If this does not relate to your CDS environment, you would probably just make that Canvas App freestanding, but I'm keeping in the lanes of business applications here. Remember that the Model-Driven app you already built has full mobile capabilities also, so you will want to explore that before you complicate things with yet another app to maintain, but for the right scenarios, Canvas is awesome. Microsoft Flow Let's say your organization has some other app they are using for other things. Let's also say that it could be advantageous to have your new app talk to that app. Maybe it would be nice to pass some data back and forth when certain things happen. Microsoft Flow is your bridge to over 250 other apps and growing. Microsoft Flow sits between your new model-driven app and any of those 250+, and can pass things back and forth based on triggers or conditions. It sounds more complicated than it is. Trust me, it's not. Not long ago, to accomplish this would have required a significant development project, all gone now. Power BI Power BI is Microsoft's industry leading Business Intelligence tool. Of course you have charts and dashboards in your model-driven app, but if you really need to go deep, or mash several sources up, Power BI is the tool for that. Of course it's primary source in your case is... you guessed it... your CDS. You can create advanced visualizations in Power BI to share with anyone, and you can even embed them into your existing app's dashboard. Is it easy? Well, it's not as easy as Flow, but you don't have to be a rocket scientist either. Another option to consider is a new offering called AI Builder. This is more of a "citizen" level tool-set that is actually quite easy to use. Not as powerful as Power BI, but it can handle a lot of AI needs. Again, sitting on your CDS. Portals Things are going quite well, and you realize there would be some efficiencies gained from having customers, vendors or partners do somethings themselves. You don't really a want to give them access to your application, but some highly filtered level of access would be real handy. This is one example where Portals come into play. A web based representation of your business application, tailored for your audience, so they can interact with you touch-free. The scenarios are limitless, but take for example a case management solution. A place where your customers could create and review cases you are working on with them in your business application. A way they can be engaged with what is going on 24/7, without having to call you for an update. All running on top of the same CDS you started with. Accelerators Let's say you are in one of the industries that Microsoft has built accelerators for, and there are several and more to come. But, for example, let's say you are in the Banking business. Your path just got shorter. Microsoft offers pre-built data models at no cost to help you get to where you need to easier. Our RapidStartCRM for Banking Accelerator is actually built on top of Microsoft's Banking Accelerator giving you...umm... double acceleration! Between these two, you may already be done before you started! Summary There are other ways to approach it, but this I my recommended path that eliminates any backing up and restarting later. Regardless of where you want to get to, Microsoft has made it exponentially easier today. Start with a model-driven app on CDS, and the sky is the limit. If you want to explore how you can move a spreadsheet based process for example, onto a platform, listen to my recent podcast with a large customer who just did exactly that.    

It seems clear to me from listening to people on social media, comments on my posts, and generally having an ear to the ground, that too many people, including many who should not be, are still confused about PowerApps... and wouldn't they be? A Quick Quiz. What is a PowerApp?  A Mobile Application you built on top of SharePoint  A Mobile Application you built on top of the common data service  A Mobile Application you built on top of Dynamics 365  A Custom Application you built in Dynamics 365  A Custom Application you built on the Common Data Service  A Custom Application you embedded into a Dynamics 365 Form  Something Else If you answered "all of the above", you get a gold star, but you're no closer to clarity. PowerApps Camps There are three primary camps for PowerApps as I see it. There are campers that come from the productivity side of the lake, where Office 365 and SharePoint live. We also have campers from the Dynamics 365 side of the lake, busily extending the Dynamics 365 applications with their own canvas and model-driven apps. Lastly, we have the Platform side of this apparently three-sided lake, using both canvas and model-driven paths to build apps from scratch on CDS. While these campers can hear the sounds of other campers across the lake, they seem to have little understanding of what the other campers are doing over there, even though they are each called "Camp PowerApp". I want to go a little deeper into the two of these camps that are part of Business Applications that I am familiar with. Someone else can speak to those productivity campers. A Custom Application I think the biggest confusion, for those of us in one or both of the Business Applications camps, are the distinction between items 4 and 5 from the quiz. "Building custom applications in Dynamics 365" vs. "Building custom applications directly on the Common Data Service". But Steve, aren't those both on CDS? Yes they are, but they got there via two distinct pathways, from opposite sides of the lake. They are not the same thing and different rules and licenses apply to each. Dynamics 365 Campers Let's face it, Model-Driven PowerApps are just XrM renamed. Everything you ever did with XrM in the past is now called PowerApps. Along the way a few more things happened, like the separation of the first-party apps from each other, and the introduction of the ability to make new role specific "PowerApps" by mashing up parts of the other first-party apps into your own concoction. Dynamics 365 brings all of the power and advanced capabilities you could want, including A.I., MR, and all the other acronyms. This is the deep end of the pool! The separation of the Apps from the underlying platform was of less importance to this camp, but actually spawned a whole new camp. Platform Campers These campers could care less about Dynamics 365. They are building their own custom apps directly on the same platform that sits under Dynamics 365. Are they masochists or anarchists? I guess a little of both. The "Platform" is actually the old XrM framework sitting on top of a database that is now called the Common Data Service (CDS). It is but a hollow shell of Dynamics 365, containing very little in the way of usable items, yet everything that is required to build as powerful an application as Dynamics 365. This is the deep end of the pool. Deep Ends If you were reading/listening closely, you heard me refer to both of these camps as the "Deep ends of the Pool". Extending the complex out-of-the-box functionality in the first-party apps requires significant skill and knowledge. But building functional, powerful and comprehensive applications on the platform also requires significant skill and knowledge. The shallow water in the middle is where "Citizen Developers" swim, creating their cute little widgets. Fuzzy Rules When it comes to the rules, there is clear separation, but for many it still seems fuzzy. Some common examples: "You can't use a Restricted Entity in a PowerApp!" This is incorrect, a clearer way to phrase this would be "If you are building a PowerApp on top of Dynamics 365, and you include in your PowerApp a restricted entity (for example the Incident entity), the user of your PowerApp will require a license that includes that entity (i.e Dynamics 365 for Customer Service)." This does not mean that you cannot build the app! Also, Restricted Entities have nothing to do with Platform Campers. There are no restricted entities in CDS without Dynamics 365. Similarly, with Team Member and it's restrictions. Team Member licenses are a type of Dynamics 365 license. Again, Team Member has nothing to do with the Platform Campers, only the Dynamics 365 campers need to be concerned with Team Member. "You cannot replicate the functionality of the first-party apps in PowerApps." This was previously true, and relevant only to the Platform Campers, but is no longer the case. For Microsoft to succeed with their Platform aspirations, it was clear they needed to eliminate any artificial restrictions, and they did. Fuzzy Licensing The recent announcement about the Platform License changes that I discussed in my last post, referenced this blog post by Charles Lamanna. Note that this post, and these licenses refer to "standalone" (aka Platform), and have nothing to do with Dynamics 365. This post and these licenses are for the Platform Campers only. You cannot use a Per App License with Dynamics 365, Dynamics 365 has it's own licenses. Similarly, the retirement of the bundled Plan licenses for Dynamics 365 has nothing to do with Platform Campers. A Fuzzy Line The line between these two camps is very clear, yet at the same time, not very obvious. There is way too much "assuming" and lazy interpreting going on, leading to way too much misinformation, leading to way too much confusion. One way to help would be, if you don't know that what you are saying is correct... don't spit it out to the world as a fact. There is an old saying, "Better to be silent and thought a fool, than to speak up and remove all doubt".

What a wonderful invention spreadsheets were. For many things, I don't know how we even managed before them. Okay, I do know, because I am that old... we managed things poorly. Spreadsheets solved so many challenges, that they eventually created new ones. 1-2-3 The first spreadsheet software I actually used was called 1-2-3 from Lotus, back around 1985. I created all sorts of spreadsheets, Shortly after, I switched up to Lotus Symphony, which was basically spreadsheet software with a programming language. With Symphony, I built a complex job-costing system for my business at the time. It was really my first experience as a "Citizen Developer". Needless to say, Microsoft eventually launched Excel, and crushed all of the other spreadsheet applications out of existence. For good reason... it was better. Access Microsoft launched another product in 1992 called "Access". It was a relational database product, and also was not the first. Some users of Excel started looking to Access as a way to build business applications. Access was "accessible", and many "normal" users built things on it. While the term "Citizen Developer" may seem recent, the concept has actually been around for a very long time. Although the tools may have changed quite a bit since then, the fundamental concepts are still pretty much the same today with the Power Platform's underlying Common Data Service (CDS)... a relational database. Fast-Forward Before I put you completely to sleep, let's jump ahead about 3 decades, to today. While the popularity of Access has waned, Excel is still very much alive. If I had to guess the percentage of businesses that use Excel.. I would put it at... 100%. It is simple-to-use, requiring almost no training at all for creating basics lists of information, and basic calculations of those items. Excel's use in organizations is ubiquitous and prolific. It is the "go-to" tool for many users, for almost anything. In fact, in enterprise organizations, I would not be surprised if the number of active spreadsheets in use is in the tens of thousands. Even small businesses often have hundreds of spreadsheets. Spreadsheets have become... an infestation. Infested It sneaks ups slowly. A business or department is formed, and there is an immediate need to capture some data. Who cares what it is, there is some shit we need to keep track of now, and the reflex is to whip up a quick spreadsheet to throw it on so it won't get lost. Makes total sense. Maybe we got a contact page on our website throwing off 5 leads a day, probably going to someone's email box. Let's put them on a spreadsheet and save it as "web site leads", and then we'll just add to it as they come in. Forget about web leads, it could be anything, but this is an easy example. So having these leads on a spreadsheet is good... we won't lose them, but we need to act on them. Next step, send a copy to our two salespeople. Today, you could actually just share it with the two salespeople, but copies are still most often the default. So now have someone updating the spreadsheet daily with new leads, and sending it to both salespeople. The salespeople are getting a daily new copy of this spreadsheet, but they have been taking actions on the last one(s). So they create a spreadsheet of their own to track their activities, and just add to it when they get the daily update. The Sales Manager wants to keep track of what is going on, so she asks the two salespeople to send her their updates daily. She then creates a spreadsheet to consolidate the two she receives. So how many spreadsheets do he have now? To be fair, a lot of this could be simplified using a shared spreadsheet, but still a spreadsheet is being used as a database. 95/5 Rule Excel was not designed to be a database, but rather a data analysis tool. The number of capabilities in Excel are staggering, yet 95% of users only use 5% of the capability. But Excel actually looks like a database table... columns for attributes and rows for records... sounds pretty similar. But used as a database, Excel gets unwieldy quickly. Imagine the scenario I described above growing over time to 50 leads a day coming in, and 20 salespeople. In enterprise businesses, I have seen similar scenarios with thousands of people trying to coordinate a business process with Excel. Excel was never intended to do that. Have you done this? I often see spreadsheets that do not use any of the calculating functions. A tab is created for each thing, like a tab for each Customer for example. On each tab are areas for the customer name, description, etc. Maybe even a running list of Phone Calls or other activities. Basically using a Spreadsheet as a quasi-CRM. I can't say this is stupid; CRM systems have become quite complex and expensive, where spreadsheets are more or less free! Tipping Point When are you torturing Excel too much? I don't need to tell you, if you have read this far your Excel-based system is already breaking down. Sally, looking at the wrong spreadsheet, calls a customer to introduce herself, only to find out that Bob called them yesterday. Bill added a note that someone needs to send Acme a price list, and nobody ever did. Joe adds a new Lead to his own copy, without realizing that Mary was already working on it. The fracture points are various and numerous. When did it start? Actually, when the second person was added to the process, the seeds were planted for it's eventual implosion. But CRM is so expensive! Think ROI It's funny some of the rationalizations customers come up with to avoid a cost. I often hear stories of massive inefficiencies costing customers thousands of dollars, followed by, "Is there a way 5 users could share a license"... to save $160! I get it... you are moving from a shit system, but it's free. But is it free? Have you taken into account anything other than a free system vs a system with a cost? SMBs really struggle with this one, focusing 100% on the possible additional cost. Easily able to ignore the costs they are currently incurring like wasted time and lost opportunities, and in a worst-case lost customers. A Path Forward Microsoft gave you the tool to create this mess, and thankfully, they also created the tools to get you out of it. You need a "Business Application" to replace your spreadsheet(s), we both know that. If you are using Excel, you probably already have other Microsoft products, like Outlook etc, or maybe even Office 365, so it makes sense to look to the same company for a solution to your Excelplosion. The main thing is, that you don't want to find yourself down the road with the same problem. Microsoft has a couple of ways to avoid that happening, Dynamics 365 or PowerApps. Let's unpack them briefly. Microsoft Dynamics 365 This is Microsoft's world-class, enterprise-grade Business Application family. If you are an enterprise, it may already be in use elsewhere in your organization. It competes head-to-head with Salesforce.com, and is a very powerful platform for solving the most complex business processes. If you have sophisticated applications in place already and are looking to move to the next level, this is something to consider. But, moving from an Excel-based system, you could not possibly have been solving enterprise-grade problems, so it could feel like a pretty big hammer. It is a big hammer, and if you are reading this post, you should ignore it completely.  Trying to go from 50 Miles per hour, straight to 500 Miles per hour, will snap everyone's neck, and you will be in an even worse place. PowerApps Now we're talking. This is exactly where you need to be going next. It is the most logical step forward from an Excel-based system. It is also significantly less expensive than Dynamics 365, and it's "Citizen Developer" friendly. My choice for moving customers off of spreadsheets is what are called "Model-Driven PowerApps", they are like Dynamics 365's little brother. They sit on the same relational database (Common Data Service) as the monster applications, but without all of the tentacles of complexity. If your needs eventually become really huge, you can easily activate the monster without having to move anything. Back to Access? If you ever worked with Microsoft Access before, PowerApps is kind of like the new version of that, but at the same time, nothing like that. The similarities are that a person with some basic technical skills can build a usable application on top of a relational database. While Access was not specifically designed for non-developers, PowerApps has enabling "Citizen Developers" as a core goal. If you don't have a comfort with basic "techy" stuff, or you don't have the time to mess with it, a partner that specializes in PowerApps can help you get there. Shameless plug: my company, Forceworks is a PowerApps partner, but the army of PowerApps partners is growing fast. Another Shameless Plug As part of our mission to move Excel-based systems to PowerApps, we created an accelerator to help customers get there faster and save some money. We call it RapidStartCRM, and you can learn more about it at https://rapidstartcrm.com. So I think that about covers it, or at least starts the conversation. It's time to stop torturing Excel, and torturing your team... you have officially run out of excuses.    

So the buzz about the Common Data Service (CDS) has reached a deafening stage. It is the most exciting thing that has come out of the Microsoft Business Applications group in a decade. The possibilities jumped into the category of "endless". So how do you start with something that is endless? Quick Primer I previously wrote about the Common Data Service here, but let's have a quick primer for this conversation. The Common Data Service (CDS) is basically a database that runs under your applications. You can have many applications running on a single CDS, all sharing the underlying data. That is pretty cool. What are these applications? Well, the list is growing, but includes things like Dynamics 365 Customer Engagement Applications, as well as Custom built PowerApps applications. Also, some other apps managed to get stood up on CDS, like Microsoft Forms Pro for example. Via connectors, you can also consume data from over 250 other sources into your CDS environment. Strategies We have what could appear to be an irony here. For the last several years, we partners have been on a mission to eliminate data silos. All of these multiple applications in use with our customers, that not only create similar data in different places, but usually don't talk to each other. There's been a whole lot of copying and pasting going on, which is not only a pain in the ass, but is inherently error-prone. It is not uncommon for an employee to have five applications open to do their jobs, and that's just silly. Part of our mission to date with Dynamics 365 has been to consolidate as many of these disparate applications into a single place. A noble goal to be sure, and a message that has resonated strongly with many customers, who suddenly found themselves sitting on a house of cards. The idea of a "Common" Data Service seems to solve all of that. But Microsoft recently announced some licensing changes, and one of the changes was that you can have as many CDS environments, as you have storage capacity to support. Wait a minute. Are we now promoting silos again? Not Common Think about a restaurant that promotes the "Best Burger in the World"... I want that. You go to get "it" and it's available in 20 variations. So wait a minute, is it the best burger, or the 20 best burgers? You ask the cook which one is the "Best burger", and he says, "it depends on what you like on it, but the beef patty, that they all come with is the best grade beef available". I ask if I can have all of the 20 variations of toppings on one burger... he frowns. But how awesome would that be? One awesome patty, with everything on top of it! Why would I want more than one? Well... maybe because peanut butter and barbecue sauce, while I like them both, don't taste good together? So let's see how I relate this scenario to CDS. Gaining Footing So CDS has been out long enough now for many of us to wrap our heads around it, at least enough to be able to explain it to customers. Now, many of us are actively deploying solutions built on CDS, and we are starting to see the scenarios forming. Scenarios that we had not necessarily contemplated before. For example, I am now being asked questions, that never were questions before like, "For this other department, should we add them to our existing CDS environment, or create a new one?" My knee-jerk response, having been a trained silo-buster, was "add them to the existing environment, or course". But is that always the correct answer? And it if was, then why is Microsoft offering them as many CDS environments as they want? Shared Data Back in the old days, if you wanted two different departments working in Dynamics 365, that did not share any data, you might have used Business Units. Or, sometimes a second production instance was used, but that had a cost. Today, you can have as many environments as your storage will support, so does that change the thought process? Today, my position on this is based on whether there is shared data. If these two departments will be sharing Accounts for example, then my recommendation would be to create a new app for department #2, specific for their needs, but add it to the existing environment. We certainly don't want to have two separate Account tables to deal with. This is the silo busting approach that we have been working towards for years now. So When? When might it make sense to create a separate environment? In my opinion, it is when the users are not sharing any data. This is a frequent occurrence in enterprise organizations in particular. Rarely have I seen HR for example, use any of the data that Sales does. In this scenario, I would take Microsoft up on their offer and spin up a separate environment. Could I accomplish this in a single environment? Yes, but it could get messy, and there is no upside any more. It is hard to completely isolate two apps from each other on the same environment. Changes to one, could potentially impact the other, if you are not paying close attention. Data segregation strategies can also get complex to maintain. Fiddle with a workflow condition for App A, and all of the sudden the records in the App B are doing weird things, if you aren't on your toes. There are a lot of ways to get in trouble if you are not right on top of it... and why bother? Licensing? On the licensing side there seems to be some confusion also, which is not unexpected. Let's say you have a sales team using the D365 Enterprise Sales app, they also have rights to PowerApps. Let's say a part of that team is focused on Lead Generation only, and not Opportunities. Clearly they will share some data, but they have different roles in the process. You can build another app on the same environment targeted to them, and they are already licensed to use it. But let's say H.R. pops up with a need for an app, and they won't be sharing any common data with sales. If those users also have a D365 Sales license, you can spin up an entirely separate environment for them and they can use that. Better yet, if H.R. does not need any of the sales related entities at all, those users could get by with PowerApps P2 licenses and save some money. However those PowerApps licensed users could not use the Sales App. There... that should be clear. Okay, I know it is not clear. Licensing is a tricky thing to navigate, but it is important to understand what licenses you need for what you are doing, or you could easily "over-license". Meaning you bought a license that allows for a lot more than what you need, and so you are paying more than you need to. I have found that Microsoft Support is often clueless to the nuances of licensing, and Microsoft Sellers are motivated to sell the most expensive licenses. Even partners struggle with this one sometimes, so it is definitely not something to figure out on your own. Your best bet is a "licensing knowledgeable" partner, which is also a rare find. I am sure there are other opinions and CDS strategies being used, let me hear yours in the comments.  

There is quite a bit of information in the wild for technically savvy people, around the Power Platform and it's underlying Common Data Service. I want to see if I can make that understandable to us Normal people. Skipping History I know, many of you were thinking, "Ugh, here comes Steve's long, drawn-out 'How we got here' story". But this is for the normal people, who don't really give a shit how we got here, they just want to know if there is something here they can make use of... or not. Platforms on Platforms In a meaningless to you nutshell, the Power Platform is comprised of PowerApps, Power BI and Microsoft Flow, each of which are kinda their own platforms. Each of these is able, but not required, to run on top of yet another platform, the Common Data Service. Additionally, they can be used individually, or in any combination. A well-known example of a PowerApp, would be the Dynamics 365 Enterprise Sales Application built by Microsoft, but you can also build your own. Multi-View Where this fits, and your interpretation of what I am saying in this post, has a lot to do with where you are. If you are currently using Dynamics 365 it may mean something different, than if you are not. For this post, I want to focus on the person who is new to all of this. Multi-Path You have several paths that you can take with Microsoft Business Applications, which one you take, will depend on what you are trying to solve for, what kind of budget you have for solving it, and how sophisticated your users are. Let's crack them open one-by-one, starting with a critical concept. No Cliffs If you have heard this term, and your name was Cliff, you may have thought you were excluded from playing. But what this really refers to is the idea, that no matter where you start, you can keep going without hitting a wall. This is a pretty unique proposition that today, only Microsoft can fulfill. With most other platforms, you will reach a cliff, a point where you can go no further without switching platforms, migrating data etc. Microsoft Business Applications are used by one-person companies, all the way up to the largest companies in the world. There are no gates, you can start with the simplest need, and keep extending, and extending with no limits. You can literally grow from a one-person firm, to a 100k employee enterprise, without ever having to change platforms. No other vendor can say that today. Big Toys We might as well start at the top with Dynamics 365, a set of world-class, enterprise grade applications that deliver an incredible array of capabilities. From Marketing Automation to Sales Force Automation, Project Service Automation and Connected Field Service Automation, all with baked-in intelligence. No other vendor comes close to what the collective Dynamics 365 applications can bring to bear, on the most advanced business requirements on the planet. While Dynamics 365 applications may be the top of the mountain, they are also the tip of the iceberg. Even these world-class applications are cliff-free with the ability to tap into Azure for even more advanced capabilities, or Microsoft Flow, to connect to vast array of other services, including competing services, who does that? Nobody else does that. Small Toys There is a growing number of enterprise organizations that are making the move to Microsoft Dynamics 365, as well as smaller organizations with complex needs. So if you are not an enterprise organization or have complex needs are you out of luck? Hardly. Microsoft has a path for every business. Let's jump to the other end of the spectrum to Micro-Businesses. 1-5, Make me Alive For a micro-business, I am going to first make an assumption that you are already an Office 365 customer. It's not a requirement, but it is a no-brainer, and opens up even more doors. Personally, I think the easiest place to get started with graduating from spreadsheets, is Microsoft Flow, hands down. A no-code solution for activating automated processes in your organization immediately. Microsoft Flow has hundreds of connections to other Microsoft and non-Microsoft services and tons of pre-built templates. From something as simple as grabbing an incoming email, and auto-replying with a Dropbox attachment, all the way through to multi-step, multi-path, multi-vendor processes spanning your entire organization. Remember, No Cliffs. Mid-Size Businesses Personally, I think the best place for a mid-sized business to start is with PowerApps. A low-code way of building simple to sophisticated apps, that are highly specific to your unique needs. If you want a head-start, check out RapidStartCRM. PowerApps can of course leverage Microsoft Flow, to supercharge your automation, all with no developers required. Level Up Once you have started collecting data and information with your applications, you may want to start adding a layer of intelligence over it so you can really get a tight handle on what's going on. This is where Power BI comes into play. Another low-code capability for gaining insights into your business at a level you probably never had before. Make a Pizza No matter where you begin, you can add any of the other ingredients, at any time, in any order, to any degree. Went big with Dynamics 365 right out of the gate? You can easy add a simple PowerApp for some other department with simpler needs. Or the other way around, started with a simple departmental PowerApp, you can easily add Dynamics 365 Connected Field Service to that. Extending Microsoft Flow with a PowerApp, or extending a PowerApp with Microsoft Flow... all possible, and easier than you think. How did this all happen? The big pivot, that really opened up all of this possibility, was the introduction of the "Common Data Service" (CDS). For most of you, this will be invisible, kind of like the engine in your car. But it is this Azure powered substrate that sits under everything I mentioned above, that lets you effortlessly snap in additional capabilities, and provides this "No Cliffs" evolution. While you don't have to even think about it, it is Microsoft's not-so-secret super sauce, that has competitors either worried, or wanting to join the Microsoft Party. Steve the Shill As I re-read this, I am realizing that I am sounding like a Microsoft Stooge. Really it is just my excitement with the possibilities overflowing onto this post, maybe as a result of my recent Summit attendance and an even  further crystallization in my head of the possibilities. I promise, I'll get back to poking Microsoft in the nose... when and if, they do anything that deserves it.    

Episode 68: Markus Erlandsson talks to Steve Mordue from Forceworks about the Microsoft Power Platform. Steve starts by explaining what the Power Platform is and how it includes the Common Data Service (CDS), PowerApps, Power BI and Flow. Steve continues how this change to the Power Platform will change the apps that we build for … Continue reading Power Platform with Steve Mordue

Dynamics 365 for Marketing - The Giant Stands Back Up Back in April, I wrote a post called "Dynamics 365 for Marketing – A Giant Tripped by a Grain of Sand" about Microsoft's new Dynamics 365 for Marketing Application. It was not a favorable post. Regardless, Microsoft added us to a very small Pilot program for the product in a, "Keep the troublemakers close" strategy. A lot has changed since then. The "Trip" In that April post, I referred to an eager fictional intern named Justin, and his lazy fictional boss, who concocted a licensing scheme for Dynamics 365 for Marketing that made no sense. The "Powers that be" recognized the error, and suggested that Justin's boss should apply for a job at Salesforce.com (and they gave him a sterling endorsement). Justin was promoted to Executive Vice President, and is now a member of the SLT. In the meantime, the non-fictional team has been hard at work, and I am pleased to report that the Giant has regained his footing. The Grain of Sand The particular issue, that stalled this product from ever reaching "greatness", was a simple one: The Licensing Model. If you recall, the original licensing model was based on the number of "Contacts" in your database. Seems simple enough, and mirrors many other competing Marketing solutions. But unlike other Marketing solutions, where the contacts that reside in them, are there specifically for Marketing purposes, in the Dynamics 365 world, Contacts is a multi-dimensional construct. With the move to Common Data Service (CDS), this was further exacerbated. In almost every customer's case, there were a significant number of "contacts" in their databases, that were not there for Marketing purposes. In some cases this was over 90% of the database! For too many customers, this was a non-starter. I am not the only one who pointed this out, many partners joined the chorus. But, like a kid incessantly pointing out a zip on your chin, I hammered on this issue in every Pilot Program call. Once something is "set" in Microsoft, there is quite a bit of bureaucracy involved in changing it. While I am sure the team would have liked me to just shut the hell up about it, it was actually the stalled motion of the product that ultimately led to revisiting the licensing model. An Almost Perfect Model I would love to report that Microsoft took my suggestion to go to a 100% consumption based model... they did not... entirely, but they did get damn close. Regardless of the virtues I see in consumption, what they came up with will work in 99% of customer cases. A complete reversal of the previous model which would only work for 1% of customers. The biggest issue has been solved: "Effective with the Oct 2018 release, pricing for Dynamics 365 for Marketing will be based only on those contacts used for a marketing activity." So it no longer matters how many contacts you have in your database, or how they got there, or why they are there. From a "Marketing" standpoint, the only ones that will count towards your cost for Marketing, are those that you are Marketing to. Hallelujah! To see the full details for the new Dynamics 365 for Marketing licensing and pricing click here to download the relevant pages of the official document. With the prior model, a conversation with a customer seldom lasted more than 20 seconds... now we can have a "real" conversation. The fact is, we still don't know if Dynamics 365 for Marketing is a world-beater, or an also-ran. It was more like a cyclist in the Tour de France, with a flat tire at the starting line, who never got to race. Well the race is about to begin, the tires are good, it's time to see if this is actually a contender... or not. BTW, I am bullish at the moment. "But Steve, you have been all over the place on this". You are free to call me a "flip-flopper". When it comes to Dynamics 365 for Marketing, that would be a fair characterization. But, I have flipped... or flopped, back to product evangelist mode. Peeling the Preview Tag I have noticed recently that many Microsoft teams, across many products, seem to be a little too eager to remove the "Preview" tag. Preview typically means the product is free to use, but is still in "Beta", and so bugs are expected. In exchange for free use, users let Microsoft know about any issues they discover, so the team can fix them before a General Availability release (Peeling off the Preview label). Some products have a high Preview signup rate, and so a good number of issues can be discovered. Unfortunately, being a new space for Microsoft, the Dynamics 365 for Marketing Preview did not have a huge number of signups. Without many bugs being reported, Microsoft apprehensively peeled the Preview tag off the Marketing App in April. Dynamics 365 for Marketing is a comprehensive application, that covers a significant number of marketing use cases. Many of these use cases clearly had not been explored by the small group of users during the Preview, and so many bugs were later discovered. In hindsight, it's probably a good thing that the licensing model kept so many customers away, as it gave the team time to address the various issues that surfaced. Bug Squishing As part of the Pilot Program, I had a front-row seat to the team's efforts to stabilize the product. I can tell you, this team was nothing short of amazing. Sometimes issues were fixed within hours. Other times, the issue was discovered to not be a bug, but simply a lack of documentation, for a brand new category of product that we were all wrapping our heads around. The team was just as amazing at plugging the documentation gaps. Many partners reached out to me to ask, "Is Microsoft serious about this Marketing thing". Based on the passion I have seen, I have no doubts in my mind about their commitment to delivering a world-class Marketing solution. If I had stock in HubSpot or Marketo, I would be genuinely concerned. Summary While the path taken by Dynamics 365 for Marketing, is probably not one that Microsoft would like to repeat, we are thankfully on the other side of that bumpy road. I look at the April launch as a "soft-launch", now we have the "real" launch. The licensing model should now make financial sense to almost everybody. The product is hardening rapidly. While the product already covers a wider swath than most any competitor, the future roadmap extends father than the eye can see. From where I was 4 months ago on it, I really have to tip my hat to the whole team. I wonder how Justin's old boss is doing over at Salesforce.com... Dynamics 365 for Marketing is a powerful solution, and as such, is also a complex solution. In addition to needing some technical chops to install and configure it, you will also need to understand Marketing in general, and how Dynamics 365 for Marketing meets those goals. To be honest, even as a 3-time Business Applications MVP, I am not well-versed enough to succeed as a partner selling this product on our own, and I'm not afraid to admit it. But I now believe very strongly in the potential of this product, and I don't want to be standing on the sidelines. So we have formed an alliance with a deep, marketing-focused Dynamics partner (Coffee + Dunn) who brings the Marketing expertise, to combine with our technical and licensing expertise. If you would like to learn more about Dynamics 365 for Marketing, feel free to reach out to either me at steve@forceworks.com, or Thomas Manders at tmanders@coffee-dunn.com.

Microsoft recently announced the availability of the Common Data Service (CDS), as a platform, accessible with a PowerApps P2 license. A few folks got kind of excited, many others said "So what?", and most have no idea what I am talking about right now. But our firm has bet the farm on it. Star Alignment Several things have happened that have led to where we are today. First, CDS 1.0 gave way to CDS 2.0, which is what we used to know of as the XrM Platform. All of Dynamics 365 Customer Engagement (CRM) runs on top of this platform, with other Dynamics 365 products making their way there over time. Second, an effort has been underway to decouple Microsoft's Dynamics 365 First-party apps from one another, and the underlying "CDS" platform. This would put them in the same position as third-party applications. Think of the Enterprise Sales App as now being a standalone product, that can be "installed" on CDS, either by itself, or alongside other first, or third-party apps that are similarly installed, like Dynamics 365 for Marketing, Field Service, ClickDimensions, etc.. Or... CDS can exist, without any first-party apps. I covered some of this in my last post, so excuse the redundancy. A Door Opens This last bit, about CDS existing without any First-party apps, is what we are focused on with the new RapidStart CRM. But before I get into why we think that makes sense for us and our customers, we have to take a short stroll down memory lane. I wouldn't be a post be me, if I didn't drag you back there, but the context is necessary. RapidStart 1.0 The original idea for RapidStart, was not original at all. In fact, other partners had been in the market with many variations of a "*Start", before we even became a Microsoft Partner in 2011. The idea is simple, and straight-forward, provide an ability for new users of Dynamics 365 to get started, with basic features, at a low cost. For us, like the other partners that were doing similar things, it was a "door-opener". We'll get you to come on-board with us, get you setup with some basics, and then help you grow from there. While some partners had created some I.P., maybe a solution, for many it was offered as a "Service"... maybe even a loss-leader. At about this same time, Microsoft was chirping in every partner's ear, that we needed to create repeatable I.P., otherwise, we were all doomed. Most partners heard this, many dismissed it as hyperbole, and most are doing just fine without converting their project services practice into an application development company. But, others took the bait, including us. I.P. Anyone? RapidStart began in 2011 as a Service offering. Later we created some I.P. in the form of a solution, and later still, we created some external I.P., our Wizard Portal. The entire offering was announced on stage at Microsoft's Worldwide Partner Conference in 2015 (what is now called Inspire). With Microsoft on-board, RapidStart really started taking off, averaging over 100 deployments a year. I will confess, that I got a little nervous when Microsoft announced the "Business Edition" for SMB, followed by great relief, when they later dropped the approach. In the meantime we had continued to evolve the RapidStart offering based on customer feedback. RapidStart had transcended from a "means to an end"... it had become an end of its own. At Microsoft's suggestion, we built a channel and together we signed up over 300 partners globally to resell and support RapidStart. Today RapidStart is the leading global solution for what Microsoft calls a "Packaged Deployment". It is one of the few third-party apps to receive the Certified for Microsoft Dynamics designation... and it's available pretty much everywhere. Things were looking pretty good. The Other Shoe While some larger companies had utilized RapidStart, by and large, it was mostly SMB focused. When Microsoft made the branding change to Dynamics 365, a new licensing model debuted with it. With much higher prices than we had previously seen for Dynamics. To be fair, this was not just a price increase for the same thing, many features and capabilities had been added, and a price increase was long overdue. But most of these new capabilities were Enterprise focused: so for most SMB customers, it was basically just... a price increase. Fortunately, Microsoft announced some promotional pricing for SMBs, dropping their price down to $40. Whew! These promos were originally intended to fill the gap until Business Edition was ready to roll out, but once Microsoft abandoned the Business Edition approach, these promos were doomed. Indeed, they fell off the price list a few months ago. While not specifically an SMB motion, Microsoft did create a licensing version of their Sales App called Sales Professional. Sales Pro is designed for users with more basic needs.. sounds kind of like SMB. This new Sales Pro App is priced at $65, 61% higher than the expired SMB promo. Ouch, that is going to make things tougher (granted, I know it is not an apples-to-apples comparison). But, while targeting users with more basic needs, the Sales Pro App is actually not any different from the full Enterprise App, except there is a list of written limitations that go with the price. I wrote about those limitations here, and about paper licensing here. So where does all that put US today? Actually... in a much better position. The primary goal of RapidStart 1.0 was to take an "enterprise level" product, and knock it down to size, so that companies of any size could actually get it successfully launched and adopted. While the needs of SMB are typically less advanced, this was also true for many enterprise level customers. RapidStart 1.0 did an excellent job of taking something complex, and making it simple. A lot of the way RapidStart 1.0 did this, was by "hiding" advanced things. There were a lot of advanced things in the enterprise apps, so RapidStart 1.0 was a pretty robust solution. But there were some challenges. Even though the bag looked light, it was actually very heavy, as it still held all of this hidden complexity. Also, customers were paying for all of this hidden complexity that they neither needed, or wanted. A Platform License As recent as 6 months ago, I was told by Microsoft that a platform, without any first-party apps, was never gonna happen. It appears that they have revisited that stance. With a PowerApps P2 license, you can indeed provision a CDS environment, without any first-party apps. For certain ISVs, like us, this "pivot" was a "game-changer". We have all no doubt heard a lot about PowerApps, mostly in the context of Canvas Apps. But "Model-Driven" PowerApps was the new secret sauce for us. This allowed us to approach the problem we are solving for, from the other side. Instead of starting with a mountain, and shaving it down to a hill, we started with a bump, and built our own hill. RapidStart CRM 2.0 The new RapidStart CRM is a simple-to-use CRM solution, built on top of CDS, without any first-party apps. The original goal remains unchanged: "provide an ability for new users of Dynamics 365 to get started, with basic features, at a low cost". Like RapidStart 1.0, we expect that many customers who launch with RapidStart, particularly larger customers, will "graduate" to the full first-party apps. In fact we are making this transition very simple to do... just one click. No migration, no downtime, no issues. Of course the licenses will need to be upgraded to the desired first-party app licenses. Also, like RapidStart 1.0, we expect many customers to be perfectly served by RapidStart CRM, particularly smaller customers, who will continue using it indefinitely. So I will have a lot more to tell you about RapidStart CRM in future posts, including our Industry specific "RapidStarts". In the meantime, you can learn more at https://rapidstartcrm.com.

PowerApps, Flow, the Common Data Service (CDS) and Poetry? Scott and Ben walk you through getting started building solutions in Office 365 leveraging these three technologies. PowerApps Modify SharePoint forms with PowerApps PowerApps pricing and skus Flows Pricing for Microsoft Flow Common Data Service (CDS) introduction Use Cases: Paul Culmsee The (new current) best way […] The post Episode 34 – PowerApps, Flow, the Common Data Service (CDS) and Poetry? appeared first on Microsoft Cloud IT Pro Podcast.