During a recent project, we began developing an application that would use the WebAPI. The application is for a client that is using Dynamics 365 On-Premises. For this setup, we used ADFS 3.0 and Dynamics 365. There is a lot of documentation from Microsoft on this process, if you are familiar with CRM development there are usually some slight differences for doing things in a Dynamics Online versus On-Prem environment. However, sometimes the documentation for on-premises misses a step or two.

The majority of the steps to get an application registered with Active Directory can be found here on MSDN, we’re just missing one small detail that can cause some non-descript ADFS errors like this:

In the article, it fails to mention the fact that we need to grant Application Permissions to the application within ADFS. Fortunately, this is a pretty easy thing to do. Just open a PowerShell prompt on your ADFS server and enter the following:

Grant-AdfsApplicationPermission -ClientRoleIdentifier “clientid” -ServerRoleIdentifier “Dynamics URL” -ScopeNames openid

After running the command, you should get a token the next time that you attempt it.

Once we started using the Web API with our API testing console, we examined the token and observed that the token was not issuing a refresh token to use. Microsoft recommends refreshing the token with every call, so this was a problem. Fortunately, this was a problem that a few minutes of research could solve; see the PowerShell below to allow the issuance of the refresh token.

Set-AdfsRelyingPartyTrust -TargetName “RelyingPartyFromADFS” -IssueOAuthRefreshTokensTo AllDevices

If you’re still not receiving a refresh token as part of an authentication response after making this change, make sure that the SSOLifetime parameter is greater than the TokenLifetime by running the Get-ADFSProperties PowerShell. A refresh token will not be issued otherwise.

For more Dynamics 365 troubleshooting, how-tos, and tips – check out our blog!

Happy Dynamics 365’ing!

In Microsoft Dynamics 365 for Sales or Service, the first-time activation of a Business Process Flow causes a corresponding Business Process Flow instance specific entity to be created.

In this article, Part 1, I will use the out-of-the-box ‘Lead to Opportunity Sales Process’ Business Process Flow to describe the properties and fields for a Business Process Flow instance specific entity.

In Part 2 of this article, I will provide more information about the ‘Lead to Opportunity Sales Process’ entity Relationships, Status and Status Reason, Records and Data

In Part 3 of this article, I will provide some interesting information on the possibility of using Import and Bulk Delete for creating, updating and deleting Business Process Flow instance specific entity records.

The following image shows this Business Process Flow displayed for a new Lead:

This Business Process Flow has four Stages that span two entities; i.e. the Lead and Opportunity entities:

Lead to Opportunity Sales Process Entity

The entity that was created when this Business Process Flow was first activated is named ‘Lead to Opportunity Sales Process’. This is an Organisation Owned entity whose properties cannot be changed. This entity is enabled for Auditing but is not enabled and cannot be enabled for anything else such as Activities, Notes, Connections, etc.

Security Roles

This entity appears on the Business Process Flows tab of Security Roles. Security Roles may then be configured to allow or prevent Users access to this Business Process Flow.
 

By default, Security Roles do not provide access to new Business Process Flows, after they have been activated for the first time, and must therefore be configured accordingly. This configuration is important for Users who need to view instances of the Business Process Flow when working with records and for analysis and reporting purposes.

Fields

The ‘Lead to Opportunity Sales Process’ entity has the following fields.
 

Those fields highlighted in blue in the above image identify those that are most useful for analysis and reporting purposes.

Active Stage Started On, Completed On and Duration Fields

The Active Stage Started On and the Completed On fields are Date Only format fields, however, they can be reconfigured to be Date and Time format fields.

The Duration calculated field is configured to calculate the difference in minutes between the Created On and Completed On dates.

Note: If the Business Process Flow is a custom Business Process Flow, rather than an out-of-the-box Business Process Flow, the Name and Schema Name of the Duration field would be ‘bpf_Duration’.

Process and Process Stage Lookup Fields

Apart from the standard Lookup fields for the Created By, Modified By, Currency and Organization there are also lookup fields to the related Process and Process Stage entities. These Lookup fields are generic to every Business Process Flow specific entity.

The Active Stage Id points to the related Process Stage entity. The Process Stage entity cannot be accessed from within a Solution or by using Advanced Find.

The Process Id points to the related Process entity. This is the entity that is displayed in the Processes area and contains a record for each configured Action, Business Process Flow, Business Rule, Dialogue Process and Workflow Process in Microsoft Dynamics 365. For Business Process Flows, the Category field in the Process entity is set to ‘Business Process Flow’.

Additional Lookup Fields

The ‘Lead to Opportunity Sales Process’ contains these additional Lookup fields. These Lookup fields are specific to this Business Process Flow. They exist because the Stages in this Business Process Flow span the Lead and Opportunity entities.

If a Business Process Flow spans only one entity there will only be one additional Lookup field. If a Business Process Flow spans three or more entities there will be three or more additional Lookup fields; i.e. one for each spanned entity.

Note: If this Business Process Flow was a custom rather than an out-of-the-box Business Process Flow the Name and Schema Name of these fields would be ‘bpf_LeadId’ and ‘bpf_OpportunityId’.

As part of the suite of features in the new Relationship Insights module in Microsoft Dynamics 365, Auto capture displays work related emails in Dynamics 365 by enabling access to your email in Microsoft Exchange.

In this demo, we give a short overview of Auto capture.

Extending Dynamics 365 is developing software, and there are processes designed for doing just that. “Agile” is a popular way to say, “Lightweight Process” or “Scrum”, but the term means much more than that – Scrum is one piece of a much larger and diverse landscape. In fact, while Scrum is extremely popular, it is focused on project management, and has little to say regarding project planning, designing code or testing strategies.

What is Scrum, and what other things does agile deal with?

In 1987, Hirotaka Takeuchi and Ikujiro Nonaka released an analysis of manufacturing companies who could pivot to rapidly meet new product opportunities. Their article “The New New Product Development Game” championed the term Scrum as a way to keep the front line of business constantly moving toward innovation and new products. Jeff Sutherland, one of the authors of The Agile Manifesto later identified this event as his inspiration for some of the first Agile process refinement. Scrum is intended to be the method for employees to drive the business forward via process and culture. To do this, Scrum is broken into Sprints that can be as short as 1 week, or as long as 4 months. Within each sprint exists a meeting for grooming a feature backlog, planning a sprint, reviewing the sprint for process improvement, and demoing the development for the business.

Why Scrum has become so popular may lie partly in its simplicity. After understanding that features go in a product backlog, and chosen features then join a sprint backlog, it becomes easy to track progress and report upward on the status of each Scrum team. One specific method for scaling upward is named Scrum of Scrums and has a similar structure not for the development team, but for a collection of Scrum Masters. In this scenario, each Scrum team reports upward to a parent Scrum team, which can continue through multiple levels of hierarchy until the top has a summary of the entire business.

Where Scrum offers a strong structure for project management, Scrum offers no recommendations on how code quality can be improved, or on individual practices for developers. This makes Scrum an easy fit with other Agile methods such as Extreme Programming or Kanban.

What do Extreme Programming and Kanban offer?

The complexity latent to software design prompted Microsoft to commission David Anderson in 2006 to study and report on how to improve productivity and increase quality. The result was to bring principles from the Japanese manufacturing methodology Kanban and repurpose them for software. In the Japanese process of Kanban, a hard limit on work-in-progress (i.e. WIP) is set to avoid overloading the manufacturing system. Similarly, a limit is set on which software features are currently being developed. When the maximum cap is met, a feature must either be completed or shelved to allow for another feature to enter the in-progress queue. By focusing on task quantity limits, iteration-less development can be achieved. This is often coupled with Scrum by limiting how many stories can be worked on by a single person at a single time, and enforcing use of a Kanban board to show stories being worked on and completed.

Extreme Programming started a bit earlier in 1996 with a publication by Kent Beck. The goal was to introduce a process that ensured high-quality code with daily releases. Since the initial article, there have been dozens of practices identified as helpful for code quality. Here are some of the more significant practices:

There are a lot more agile practices out there. A few of dozens would include Feature Drive Design, Crystal, Rapid Application Development! They are all intended to make quality software better and faster, which is a great thing for Dynamics 365.

Subscribe to our blog for more great Dynamics 365 related topics!

Happy Dynamics 365’ing!

In my previous article, I demonstrated how to configure a Workflow Process to set any User Lookup field to the Current User using the standard Modified By field to set a custom field named Last Updated By.

In this article, I provide additional important information that you should be aware of.

Real-Time Workflow Processes

When using a Real-Time Workflow Process, there is an option to configure the Workflow Process to automatically start either after or before a Contact has been updated.

It is important to ensure that the Workflow Process is configured to automatically start After, instead of Before the designated fields on the Contact are changed otherwise the Contact Modified By value used to set the Last Updated By field will contain the previous User who modified the Contact, instead of the current User. This will result in the Last Updated By field being incorrectly set.

Here is what happens when the configuration for automatically starting the Workflow Process is set to Before the Contact is updated; i.e. Before Record Fields Change.

When creating a new Contact the Last Updated On and Last Updated By fields are correctly set to the current Date/Time and User.

However, if another User now updates one of the designated fields on the Contact the Last Updated By field is incorrectly set to the User who previously modified the Contact rather than to the current User.

e.g. incorrectly to this …

… rather than correctly to this …

Background Workflow Processes

If using a Background Workflow Process, there is no option to configure the process to automatically start Before a Contact has been updated. A Background Workflow Processes that is configured to automatically start when a Contact has been updated will always start After the Contact has been updated.

Real-Time vs Background Workflow Processes

In this example used in Part 1 of this article, I chose to use a Real-Time Workflow Process instead of a Background Workflow Process to ensure that the update of the Last Modified On and Last Modified By fields was immediate.

This has the following benefits:

• The Workflow Process starts immediately. If a Background Workflow Process was used there is a short delay between when the designated fields on the Contact were updated and when the Workflow Process starts. It is possible within this short time for some other User, or process, to update other fields on the Contact resulting in the Modified By field being changed to that other User. Then, when the Workflow Process populates the Last Updated By field it will be set to that other User, rather than to the current User who updated any of the designated fields.
• The Last Modified On and Last Modified By fields if displayed on the form are immediately updated and visible without needing to refresh the form. If a Background Process was used the form would have to be refreshed before the changes to these fields would be displayed.

Other Scenarios

Sometimes you may encounter a scenario where you want to use a Workflow Process to set a User Lookup field on a record to the current User when there has been no corresponding creation or update of the record on which the User Lookup field is located and therefore no corresponding update of the Modified By field.

This may be because:

• The Workflow Process is started On-Demand, or manually, by a User without any corresponding changes being made to the record against which it was started.
• The Workflow Process is automatically triggered by the creation or update of some related record such as an Activity, Case or Opportunity etc. instead of by the creation or update of the record on which the User Lookup field exists.
• The Update step in the Workflow Process occurs after a Wait Until or Parallel Wait step; i.e. a Timeout period. Note: This scenario only applies to Background Workflow Processes.

In this situation, one of the following two approaches might be used to ensure that the User Lookup field is correctly set to the current User.

First Approach

Configure the Workflow Process with two successive Update steps as follows:

• Configure the first Update step to change an unused field. This change to the unused field will also cause the Modified By field to be updated. Note: You must ensure that this step always makes a change to the field. You can do this by selecting an unused Date/Time or Text field and configure the Update step to set that field to the Process Execution Time; e.g. for a Contact you could set the unused Pager field to the Process Execution Time. This is a text field. Note: If using an unused Date/Time field the Format must be Date and Time rather than Date Only.

• Configure the second Update step to set the Last Updated On and Last Updated By fields from the Process Execution Time and the Modified By field.

This approach works well if you don’t mind making two successive updates to the record.

Note: If you are using a Real-Time Workflow Process, ensure the Workflow Process is configured to run as the User who made changes to the record rather than the owner of the workflow, otherwise the first Update step will result in the Modified By field being set to the owner of the Workflow Process rather than to the current User. This option does not apply if the Workflow Process is started On Demand, manually, by a User, but is does apply if the Workflow Process was started automatically.

Hint: You could bundle these two Update steps into one single Action or Real-Time Child Workflow Process and then invoke that Action or Child Workflow Process from any other Workflow Process, Dialog Process or Action whenever required using a single Perform Action or Start Child Workflow step.

The following images show:

• A Perform Action step in a Background Workflow Process that starts an Action named UpdateLastUpdated Fields. Note: Actions always run in Real-Time.

• A StartChildWorkflow step in a Background Workflow Process that starts a Real-Time Child Workflow Process named Update Last Updated Fields.

Second Approach

Configure the Workflow Process to first start a Custom Workflow Activity that then returns the UserId of the User that the Workflow Process is running as and then use an Update step to set the Last Updated On and Last Updated By fields from the Process ExecutionTime and the previously returned UserId.

This approach:

• works if the Workflow Process is running as the current User.
• Requires the development and publication of a suitable Custom Workflow Activity that returns the UserId of the User that the Workflow Process is running as.
• Requires only one rather than two updates to be made by the Workflow Process to the record being updated.

Microsoft Dynamics 365 for Sales and Service supports the use of multiple activated Business Process Flows for an Entity. In addition, Microsoft Dynamics 365 allows multiple concurrent Business Process Flows to be started against a record such as an Account.

In this article, I will demonstrate, using a first set of six sequential scenarios, which Business Process Flows users will see displayed for an Account when multiple concurrent Business Process Flows have been started for the Account. These are designed to demonstrate what happens when using Switch vs. Next Stage.

The sequence of these scenarios differs to that in my next article.

In my fourth and final article, I will describe the underlying rules that determine for all twelve scenarios which Business Process Flow is displayed to Users who have not previously viewed the Account when they view it for the first after the first Business Process Flow has been started for the Account.

SCENARIO 1A (CREATE):

Refer to my previous article in this series.

SCENARIO 2A (START):

James now uses Switch Process on the Process button of the Command Bar to start the ‘Setup Account Process 2’ Business Process Flow for the Account.

As the result of this action:

• There are now two Business Process Flows started for the Account.
• I will continue to see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account.
• James will now see the ‘Setup Account Process 2’ Business Process Flow displayed for the Account from this point forward.
• If another User, such as a User named Wilson, now views the Account for the first time since the first Business Process Flow was started he will see the ‘Setup Account Process 2’ Business Process Flow displayed for the Account whenever he views it from this point forward.
• If Wilson creates a new Account, the ‘Setup Account Process 1’ Business Process Flow will be automatically started and displayed for the new Account.

SCENARIO 3 (SWITCH):

Wilson now uses Switch Process on the Process button of the Command Bar to start the ‘Setup Account Process 3’ Business Process Flow for the Account.

As the result of these actions:

• There are now three Business Process Flows started for the Account.
• I will continue to see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account.
• James will continue to see the ‘Setup Account Process 2’ Business Process Flow for the Account.
• Wilson will see the ‘Setup Account Process 3’ Business Process Flow displayed for the Account from this point forward.
• If another User, such as a User named Timothy, now views the Account for the first time since the first Business Process Flow was started he will see the ‘Setup Account Process 3’ Business Process Flow displayed for the Account whenever he views it from this point forward.
• If Timothy creates a new Account, the ‘Setup Account Process 1’ Business Process Flow will be automatically started and displayed for the new Account.

SCENARIO 4A (CHANGE ACTIVE STAGE):

I now advance the ‘Setup Account Process 1’ Business Process Flow to the Next Stage.

 
As the result of this action:

• I will continue to see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account.
• James will continue to see the ‘Setup Account Process 2’ Business Process Flow displayed for the Account.
• Wilson and Timothy will continue to see the ‘Setup Account Process 3’ Business Process Flow displayed for the Account.
• If another User, such as a User named Jane, now views the Account for the first time since the first Business Process Flow was started she will see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account whenever she views it from this point forward.
• If Jane creates a new Account, the ‘Setup Account Process 1’ Business Process Flow will be automatically started and displayed for the new Account.

SCENARIO 5A (SWITCH): Jane now uses Switch Process on the Process button of the Command Bar to switch to ‘Setup Account Process 2’ Business Process Flow for the Account.

As the result of this action:

• I will continue to see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account.
• James will continue to see the ‘Setup Account Process 2’ Business Process Flow displayed for the Account.
• Wilson and Timothy will continue to see the ‘Setup Account Process 3’ Business Process Flow displayed for the Account.
• Jane will now see the ‘Setup Account Process 2’ Business Process Flow displayed for the Account from this point forward.
• If another User, such as a User named Susan, now views the Account for the first time since the first Business Process Flow was started she will see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account whenever she views it from this point forward. Note: This differs to the previous scenarios where a user switched to another Business Process Flow because this switch of Business Process Flow was a switch back to a previously started Business Process Flow.
• If Susan creates a new Account, the ‘Setup Account Process 1’ Business Process Flow will be automatically started and displayed for the new Account.

SCENARIO 6A: (REMOVE ACCESS):

The configuration of the Security Roles assigned to each of these Users and to the Teams of which they are members are changed so that they no longer have access to the ‘Setup Account Process 3’ Business Process Flow.

As the result of this action:

• I and Susan will continue to see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account.
• James and Jane will continue to see the ‘Setup Account Process 2’ Business Process Flow displayed for the Account.
• Wilson and Timothy will now see the ‘Setup Account Process 1’ Business Process Flow displayed for the Account from this point forward.

 Aiden Kaskela (center) and other "Medics" at D365UG/CRMUG Summit 2017

Before finding his way to the world of Dynamics CRM/365, newly awarded Microsoft MVP Aiden Kaskela was in the midst of a six year run with the Pennsylvania Air National Guard working on cryptographic and networking systems for deployed units.

Kaskela, who has been programming since he was in high school, was first introduced to Dynamics CRM by his best friend, who also turned him on to h...

read more

PowerObjects had boots on the ground in Nashville for the annual D365UG Summit. The PowerObjects team of over 20 representatives presented at over 16 sessions, gave away 1,500 D365 hoodies, and sported one GIANT D365 sign at our booth. From photo ops to classroom chats, see how our week went in this episode of Dynamics 365 In Focus.

When a new Microsoft Dynamics 365 release comes out I like to make a list of all the areas that changed, features added, etc.  I’m a list type person so getting organized around this list helps me ensure I’m aware of, and at a minimum, do some research on each one to gain some familiarity.  Today, I found myself making my list for the latest release.  Yes, I’m a little behind but still moving forward so that’s a positive!

Since I made the list, I thought I would share it with you so we can take this journey together.  Here goes:

• Activity Timeline
• Activity Management
• Connected Field Service
• Customer Service Hub
• Live Assist for Dynamics 365
• Microsoft Social Engagement
• Mobile Experiences
• Mobile Offline
• Resource Scheduling
• Resource Scheduling Extensibility
• Resource Scheduling Optimization
• Unified Interface
• Application Module and Designer
• Customer Engagement Portals
• Dynamics 365 Connector for LinkedIn
• LinkedIn Sales Navigator
• Unified Service Desk
• Virtual Entities
• Application Platform Separation
• Business Process Automation
• Customer Insights – Segmentation
• Customer Insights – Data Connector
• Customer Insights – Predictive Match
• Customer Insights – Predictive Scoring
• Data Export Service
• Dynamics 365 Data Integration
• Multi-Select Option Set
• Organization Insights
• Productivity and Relationship Insights
• Security Enhancements
• Solutions
• Web Client Visual Refresh

   

You can review and monitor the Dynamics 365 Roadmap and What’s New area of Microsoft Docs for similar and additional information on each of the changes.  You can also spin up a new trial and have a look at each of the areas to see if you can discover whats changed.

Feel free to add anything I missed in the comments area.  I look forward to hearing from you.

Cheers

Put away the calculator and let taxes calculate themselves!

Sure, you can enter taxes in Microsoft Dynamics 365 for Sales (formerly CRM), but wouldn't it be nice if you didn't have to calculate them too? With the Rockton Software Tax Processing app, the taxes are calculated for you. This means your taxes will be more accurate and your team will save time when entering records.

The set-up is simple. You create Tax Details that define what your tax amount or tax percentages are to be calculated. Create as many details as you need. Then, simply assign those Tax Details to a Tax Schedule. For example, you may have a city tax, a county tax, and a state tax that all need to be calculated on one document. Create a Tax Detail for each of them and then assign all three to the Schedule. When that Tax Schedule is used, those three taxes will automatically be calculated. To make things even easier, you can assign default Tax Schedules to your Products or Customers. On the Product you determine whether the taxes are to be based on Product, Customer, or no tax at all. Then, when you enter a record, the Tax Schedule will default and taxes will calculate.

Tax Processing will work with Opportunities, Quotes, Orders, and Invoices in Microsoft Dynamics 365 for Sales. As an added bonus, Rockton Software has included an additional document called Sales Documents. The Sales Document offers you the flexibility to have additional Document Types as well as have more control over the Document Number. This is beneficial should you integrate with other ERP systems.

For more complex tax situations or when you have tax amounts/percentages that are frequently changing, you might use Avalara AvaTax. The Tax Processing app will integrate with AvaTax too. This way you can establish your own custom taxes or use the built-in integration with AvaTax.

Tax Processing is now available for download on the Microsoft AppSource. Also, for a limited time only, download a free trial and be eligible for 6-Months FREE! If you would like to see a personal demo or if you have more questions on Tax Processing, contact our sales team at sales@rocktonsoftware.com.

The post New Tax Processing App in D365 for Sales (CRM) appeared first on CRM Software Blog | Dynamics 365.