When it comes to creating a contract with Microsoft Dynamics 365 Project Service Automation (PSA), users often find that the path from opportunity to quote and contract is long, slow, and involves too many clicks. To make it more efficient and cut down on the number of clicks, we can combine the capabilities of Power Apps with Power Automate flows. People love tooling that helps take care of small steps automatically like creating a basic project-specific price list, the Quote line details, or milestones. Let’s understand what’s involved at each step to go from Opportunity to Quote to Contract and navigate the entire process more effectively. Navigating the process Step 1: Create the Opportunity by navigating to Opportunity Entity in Project Service App. Step 2: When saving the opportunity users run a Power Automate flow behind the scene that does the following things: 1. Create the Quote automatically based on the billing type. 2. Generate the Quote Line record. 3. Fills the project-specific Price List (developed in Power Apps). This is now very easy to edit since the interface becomes more user-friendly and it directly updates the Roles Prices in the Pricelist. This, too, is a lengthy process with the out of the box capabilities of PSA. 4. Generate the Quote Line Detail, with one line developed in Power Apps. The details will include: a) Developer b) Quantity set as one hour c) Choose the rate from the default pricelist on the opportunity. Step 3: Now the Salesperson opens the Quote Line Details to add more lines in case needed. For this, I prefer adding one line to each role and adjusting the quantities appropriately to reach the quote amount. Step 4: After the Quote is ready and the negotiations are done with the client, we proceed to win the Quote, which does the following: Marks the Quote as won Creates the contract automatically with all the information in the quote (using an OOB feature) Automatically marks the related Opportunity Won. This is done via a flow which looks for the Opportunity from where the Quote was created and marks it as won. This is typically a manual process in PSA, but using Power Automate, users can also first navigate to the opportunity and mark it as won. Conclusion This process demonstrates the power of Power Automate flows and how much time they can save for a salesperson. The regular process takes lots of clicks and entries to be done right and hence is time consuming when done manually. Power Apps also helps you improve the UI and enrich the look and feel of the app. It also helps in reducing the navigation between entities and thus saves a lot of time.

Introduction: Once a User exports a report to Microsoft Excel from a Microsoft Dynamics CRM environment, they may want to further filter the report in Microsoft Excel. Issue: An issue I came across recently was that the report, when exported to Excel, would not allow me to filter in Excel for the first few columns, as shown in the screenshot below. On further testing, I found that this was due to the Title text box above the table. Solution: Once the side of the text box was extended to the very end of the report (as shown above), near the end of the page, Excel allowed the filters to be applied to all columns in the exported SSRS report. That solves it!

Introduction: In this blog, I will detail how to migrate Activity Parties of Emails from one CRM to another. In my previous blog, I outlined the first step of the Email migration process which is migrating the body of the email. Migrating the corresponding Activity Parties of an Email is the second step of this process, as the Email body now exists in the Target CRM. What are Activity Parties? Other than the Body, an Email Activity consists of: Sender: The person(s) sending the email. Recipient: The person(s) receiving the email. CC & BCC: The person(s) that are copied in the email. Owner: The person who is the owner of the email. Regarding: This generally links to an entity in CRM which pertains to the email. For example, a Case or a Project in CRM. ‘Sender’, ‘Recipient’, CC’, ‘BCC’, ‘Owner’ and ‘Regarding’ are each stored in CRM as a separate Activity Party of that email with a ‘Participation Type’ code (field name: ‘participationtypemask’) to establish the field that specific party belongs to i.e. 1 = Sender, 2= To Recipent and so on (as shown below). Generally, in an Activity Party, the person(s) are either System Users or Contacts. This is specified in the field ‘partyobjecttypecode’ as shown above. Keeping this in mind, one can lookup to these entities to obtain the corresponding GUIDs in the Target System and map it as the ‘partyid ‘. After the Activity Party is created, the owner of the Activity Party should be updated as per its owner in the Source environment. The ‘Owner’ Activity Party is automatically created by CRM as the same User as the Owner of the Email (configured when you migrate the Email Body in Step 1). The ‘Regarding’ Activity Party links to a Case/ Project and not a ‘person’, however, the same logic applies i.e. map the required GUID and its type. Migrating Activity Parties is not as complicated once understood. Unfortunately, not much is easily available online about this. I hope this blog demystified a few concepts about Activity Parties of an Email and how they can be migrated from one CRM to another. My next blog will detail how to migrate Email Attachments and update the status of an Email.

Introduction: Data migration can be a little challenging, especially when it comes to Emails. In this blog, I will outline the steps that need to be followed to successfully migrate Emails as well as important things to keep in mind during the process. Steps: There are four main steps to follow to successfully migrate an Email from Source to Target: Send the body of the Email. Send all the related Activity Parties. Send the details of the related Email Attachment(s). Update the Status of the Email. In this blog, we will be dealing with the first step i.e. creating the map in TIBCO Cloud Integration to send the Body of an Email. Migrating the body of the Email is straightforward compared to the next step but there are a few aspects to keep in mind: 1) Send the email as Open so that Activity Parties and Attachments can be migrated in the following steps. Not sending the email with an “Open” status could lead to Activity Parties and Attachments not being migrated to the corresponding email. 2) When an email is migrated, the owner of the email will be the User configured in the CRM Connection in Scribe. In order to maintain the same owner as in the Source, you can update the email with the correct owner after it is created. In the screenshot below, I am using a Lookup Table in Scribe to map the User GUID of the Target System. 3) If you want the GUID of the email to remain the same in Source and Target, do not forget to map the ‘activityid’ of the Email entity. Conclusion: I hope this blog provided some insight into the migration process for Email Activities. In the next blog ‘Email Migration from CRM v8.2 to CRM v9 using TIBCO Cloud Integration: Activity Parties‘, I will talk about migrating ‘Activity Parties’ which can be the most challenging part of Email Migration.