Summary SIP Industries is a Houston-based manufacturer of engineered components. Every new part it makes goes through a six-stage New Product Development (NPD) Business Process Flow in Dynamics 365. Most of the people who approve those stages never open the CRM. They include plant engineers and QA inspectors in India, the U.S. engineering team and customer reviewers. They replied by email, and the CRM team typed each reply into the NPD record and then clicked Next Stage by hand. We replaced that manual relay with three Power Automate flows, plus a small daily reminder flow. Each approver gets an email with one button, which opens a pre-filled HTML form that needs no login. The flows save the answers to Dataverse and move the stage forward once its conditions are met. Nobody keys in approvals or moves stages by hand any more. SI SIP IndustriesEngineered components manufacturer, Houston, Texas Industry Manufacturing Region United States StackDynamics 365 SalesPower AutomateMicrosoft DataverseSharePoint Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Business Impact→ Conclusion→ Connect With Us→ Business Challenges SIP already had a working NPD Business Process Flow on a custom New Product Development table. The stage design was sound. The time went into one recurring loop that the CRM team ran by hand for every stage of every part. New Product Development View A CRM user emailed the approver for that stage and attached or linked the latest drawing The approver replied in the thread, often with a one-line "go ahead" and an estimate buried in the text The CRM user read the reply and typed the decision, notes and dates into the NPD record The CRM user opened the Business Process Flow and clicked Next Stage The CRM user emailed the next team to tell them it was their turn That loop broke down in four specific places. Licensing the approvers was never realistic. A customer reviewer who signs off a sample twice a year does not need a Dynamics 365 seat, training and a password to remember Some stages close on more than one decision. Feasibility needs feasibility approval, engineering approval and a created engineering drawing. First Article Inspection needs both the India QA team and the U.S. engineering team. These approvals arrived in any order and someone had to keep track of which were still missing Drawing approvals stalled for weeks. Nothing reminded the reviewer, so follow-up depended on a CRM user remembering to chase The audit trail lived in personal mailboxes. Opening the NPD record told you the current stage, not who approved it or when Solution Overview We put an email-driven approval layer on top of the existing NPD process. When an NPD record reaches a stage, Dynamics 365 emails the approver for that stage. The email is written for that stage, so a Pattern request shows pattern details and an inspection request shows inspection details. It ends with one button. Engineering Approval Request Received in Outlook The button opens a web form in the approver’s browser, already filled in with whatever the NPD record holds. The form lists the product’s SharePoint documents and accepts new uploads. The approver picks a decision, adds notes and submits. Feasibility Approval Form Dynamics 365 then saves the answers into the right NPD fields. It moves the process to the next stage if that stage’s conditions are now complete, and the next approver gets their email. A rejection or a "Requires Changes" answer keeps the record in its current stage and notifies the NPD team instead. ⓘWho still uses the CRM The NPD team still works in Dynamics 365 and can set any field directly. The automation responds to changes made in the CRM in the same way as changes made through a form. Technical Approach Architecture at a Glance TriggerNPD record savedStatus or an approval field changes Flow 1Send Approval EmailTracked email with a stage-specific button Flow 2Show Approval FormReturns pre-filled HTML for the stage Flow 3Save Approval ResponseWrites answers and uploads to Dataverse and SharePoint DataverseBPF advancesNext stage starts and Flow 1 fires again These three flows run the entire approval loop, and the loop closes itself. When Flow 3 saves an answer, the NPD record changes, and that change triggers Flow 1 again. Flow 1 then either moves a stage whose conditions are now all met or sends the next approver their email. Alongside the loop, a separate reminder flow runs once a day and chases open drawing approvals. Six Stages, Eight Forms New Product Development Form Stage Approver Form Captures Stage Closes When Feasibility Feasibility team, Engineering team Feasibility approval, engineering approval, notes, estimated development timeline, estimated tooling cost Both approvals recorded and engineering drawing created Drawing Approval Drawing reviewer Drawing received, sample required, feedback, approval Reviewer approves on the form Pattern Plant and tooling team Pattern status, foundry, notes Pattern Status set to Ready For Inspection First Article Inspection India QA, U.S. engineering FAI approval and date, sample sent to U.S., shipment date, U.S. approval and comments Both India and U.S. approvals recorded Customer Approval Customer Yes, No or Requires Changes, with the approval date set automatically Customer answers Yes Production Production team Release notification Final stage NPD stages, approvers and the condition that closes each one Six stages produce eight forms because two stages have two separate approvers. Feasibility has one form for the feasibility team and one for engineering. First Article Inspection has one for India QA and one for U.S. engineering. Each form is identified by a stage key: feasibility, engineering, drawing, pattern, fai, fai_us, customer and production. Each form shows only the fields that apply to the record. The India FAI form asks whether a sample was sent to the U.S. only when the drawing reviewer marked a sample as required. It asks for the shipment date only after the sample has gone. Why the Form Lives Inside Power Automate Criteria Power Pages Canvas App Our choiceHTML form from Power Automate Approver opens it without signing in ✗ ✗ ✓ No … Continue reading How a U.S. Castings Manufacturer Saved Time by Updating Dynamics 365 Without Logging Into CRM →

Introduction: In this blog, we will see how to set up email parameters and SMTP configuration for sending test mail from Microsoft Dynamics 365 Finance and Operations. Details:  Go to the Email Parameters by follow this path: System administration -> Setup -> Email -> Email Parameter. Another easiest way to find the email parameter in a quick manner, go to the search box and simply write email parameter as below shown screenshot Steps:  1. In the configuration tab, set up the SMTP as in shown below image Move SMTP in the right box named with ENABLED to enable  2. In SMTP settings tab, configure the below stuff:      Outgoing mail server: smtp.office365.com     SMTP port number: 587     Username: put the email id from which email should be sent      Password: appropriate password of the email     Specify if SSL is required: true 3. In Test mail tab:      Email provider: SMTP     Send to: Put the email to whom test mail should be sent  In the final, click on the “Send test mail” and then sample mail will be sent to the respective email address.      Conclusion: In the above blog, we have seen how to set up SMTP configuration to test “send email” functionality from the email parameter form.  Thanks for reading !!!

Introduction: While migrating Email Activities from D365 v8.2 to v9, I came across the following error: “Operation failed. Label: Create email, Name: emailCreate2, Message: -2147220969: ActivityPointer With Id = XXXXXXXXXXXX Does Not Exist” This can cause some confusion as activitypointers do not need to be migrated before you begin migrating emails. What are ActivityPointers? The activity pointer (activity) entity represents any activity or task that is performed, or to be performed by a user. An activity is any action for which an entry can be made on a calendar. Whenever you create an activity record in Microsoft Dynamics 365, a corresponding activity pointer record is created. This indicates that the activity record and the corresponding activity pointer record have the same value for the ActivityId attribute. For example, if you create an Email record, the attribute values of Email.ActivityId and the corresponding ActivityPointer.ActivityId will be the same. This should not be confused with ActivityParties which represent a person or group associated with an activity. An activity can have multiple activity parties. Cause: Upon inspection, I discovered that those emails are linked to themselves, having the ‘parentactivityid’ field populated with its own activity GUID. The error was being caused because Scribe could not find the parent activity in the Target environment (since it had not yet been created). Solution: Remove the ‘parentactivityid’ mapping from the ‘Create Email’ block. Add an If-Else Block below the Create block to check if the Email has been created, and if true, use an Update block to update the Email with the ‘parentactivityid’. Now, the Email activity will be created with the correct GUID and once created, will be updated with the required GUID as ‘parentactivityid’. This solution resolved the above issue and email activities  can now be created without this error occurring.