Automate This! — Asset Management with Flow and MuleSoft Composer

The business case

When sales closes a deal, it’s a celebration, but the work has only just begun for the back-office support and field service teams. It becomes a difficult juggle when multiple teams have to coordinate together to pass information across systems about shipment details, installations, and device attributes, and to keep said systems up to date with all that detail. Manually managing this information handoff works well for small teams, but as teams grow, the game of information hot potato no longer works.

The business needed a leaner and more automated solution to create asset records with known details based on won opportunity information and update the asset record with serial information when the sold device shipped. Using Flow Builder, it becomes easy to automate record creation and apply known details based on business rules. Leveraging MuleSoft Composer, shipment and serial details housed in the enterprise resource planning (ERP) suite, NetSuite, can easily be copied over to the related Salesforce record(s).

The solution

To automate asset creation from a booked order in NetSuite, I had to first design a data model that followed the business workflow. In our scenario, each NetSuite order had a sister order record in Salesforce relating back to the won opportunity. Once the Salesforce order record was established and linked to the NetSuite order record, I then connected it to the Asset object using a custom junction object called “Order Assets.”

Business process

The business process was linear. Every time an opportunity/quote was won, a Salesforce order was created and replicated in the ERP, and lastly, the sold hardware (device) was represented as an asset record in Salesforce.

Data model

The resulting data model mirrored the business process in its linear fashion. Quotes are connected to Salesforce orders, which are then connected to an outside source (ERP orders) and internal records (order assets and asset records). Because an order can have multiple products, it makes sense to make the relationship one to many (one order to many assets). The Order Assets junction object allows for this structure.

As an Awesome Admin, you may have noticed too, in this diagram, where Composer is used and where Flow is used. So, let’s talk about it now!

User experience

For an enhanced user experience, our goal is to automate data entry when and wherever possible, especially when the data is already known or self identified based on business rules. In this example, the business rules require the Salesforce order to be approved before being booked in the ERP (NetSuite). The business process act of approving the Salesforce order triggers the MuleSoft Composer flow to mule over order detail attributes to create the sister order record in the ERP. Once completed, MuleSoft Composer updates the Salesforce order record with the ERP order number, thus linking them together by each other’s primary keys. (In Salesforce, MuleSoft Composer stamps the ERP order number, and in the ERP, MuleSoft Composer stamps the Salesforce order number.)

Once linked and order creation has been deemed successful in the ERP, Flow runs next creating the related order asset and asset records based upon the products listed on the Salesforce order. That’s right! Since Flow can listen for record changes, the instant MuleSoft Composer updates the Salesforce order with the ERP order details, the flow kicks off. The first flow creates placeholder asset records and asset order records. Since we know which products were purchased, we now know enough to create an asset record identifying the product, parent order, customer/account details, as well as the primary contact. All are copied over from the original Salesforce order and related quote records.

Above, this flow is covering a lot of actions. First it’s evaluating if the Salesforce order record was updated with the ERP order details passed back, when successful, from MuleSoft Composer. If successful, the flow Gets Records of the the order’s related product records.

The elements encased in the blue box represent the evaluation step to determine how many asset records to create based upon which products and the the quantity sold.

The elements encased in the red box represent the step to create the necessary number of asset records.

The elements encased in the green box represent the step to create the necessary order asset junction records and link the created assets back to the originating Salesforce order.

Even though nothing has been shipped to the customer yet, the placeholder asset records are created with the known information from the order, sold products, and opportunity details.

Wait, what?

Why is this step occurring now, before things ship? Because it positively informs and proactively communicates to the downstream teams which hardware was sold to which customer so they can plan ahead. Who doesn’t love advance notice?! By automating the asset record creation process, downstream teams of sales gain time back and reduce the risk of potential errors or forgetting to even log a sold hardware instrument. These same teams can proactively reach out to schedule customer visits (things they were already doing, but now, doing sooner than before).

To recap where we are in the business process, steps 1–3, and only part of step 4, have been completed. We’ve created asset placeholders with the known information from the Salesforce records, but the last piece is to have the shipment details, which contain serial numbers and tracking numbers from NetSuite, pass through into Salesforce and update the asset placeholder records. So, let’s cover that now!

Time is on your side

We all know that shipping out hardware can take time, especially if you’re making it to specification. Like Flow, Composer doesn’t care how long it has to wait; it’s always listening for that triggering event. So whether it’s 1 week or 20, Composer is ready and waiting! To complete out the process, shipment details from the ERP (NetSuite) need to be passed back into Salesforce and update the related order’s assets. This time, we’re starting with Composer since the triggering event is in NetSuite.

Before we hop into Composer, let’s write out this next step and understand what it’s supposed to do. This will help with reading the flow. The problem statement we’re solving for is, “When a NetSuite order is updated and has a related Salesforce order record, and is updated with shipping details, update the Salesforce order record with the shipping details.” It seems pretty straightforward, but you’re an Awesome Admin, so you know there’s more to consider. For example, just like Salesforce opportunities, orders have stages. Each stage represents a different step in the order process. So, we don’t want to fire our Composer flow for every change, just the ones that pertain to shipping. We’ll want to consider those specific statuses when building out the flow. Remember! Understanding the business process will help keep your flows running lean and reduce risk for false alert errors. Okay, so it’s time to go with the Composer flow.

For those seeing Composer for the first time here, it’s important to note that Composer is linear in its design, where Flow is more free-form. With Composer, node location matters, and the trick to success is knowing when to nest your action versus not. If you love algebra, Composer will be your jam. Because of their linear fashion, we’ll break down this example flow into sections. (Hint! Nodes are numbered to keep you organized!)

Node 1 is our listening trigger. Composer is listening for when there’s a change to any order record in NetSuite.

This is the first part of our problem statement, “When a NetSuite order is updated and has a related Salesforce order record, and is updated with shipping details, update the Salesforce order record with the shipping details.”

Node 2 is our first If/Else statement block that houses all the actions to take if the If statement evaluates to true. The first IF statement actually lives in Node 3.

Here we want to evaluate only NetSuite order records that also have a Salesforce order number stamped on the record. (Remember that from above? We want to marry the two records by stamping each other’s primary key on the other’s record.) If the updated order from Node 1 does have a related Salesforce order number, then move into our next nested If statement.

This is the second part of our problem statement, “When a NetSuite order is updated and has a related Salesforce order record, and is updated with shipping details, update the Salesforce order record with the shipping details.”

Node 4 is our second and nested If/Else statement block. In it, Node 5 is where we evaluate our order status to identify if it is a status where we’d expect to see shipment details.

“When a NetSuite order is updated and has a related Salesforce order record, and is updated with shipping details, update the Salesforce order record with the shipping details.”

Node 6 is where we have our action! We’ve passed through all the If/Else statements and they’ve evaluated to true, meaning we’re coming to the last part of our problem statement. In Node 6, similar to a “Get Records” in Flow, we want to grab the corresponding Salesforce order record. Once we have our record(s), in Node 7, we iterate through the found record(s) to update them in Node 8. Wait? Did I say “iterate through the found record(s)”?! That's right admins, it's just like a Flow loop, but visualized in a linear fashion!

“When a NetSuite order is updated and has a related Salesforce order record, and is updated with shipping details, update the Salesforce order record with the shipping details.”

Whew! We did it! Our Composer flow successfully updated our related Salesforce order record with shipping details. But wait, we’re not done. We still need to update our asset placeholder records, remember those?! For this last part, we return to our old friend, Flow. Again, using a record-triggered flow, when the Salesforce order is updated with shipping details, it knows to take action! Let’s see how Flow brings us home.

The job of this flow is to listen for changes to the order fields that contain shipping details and to process the information within those fields. We need to take the shipped serial numbers and update each placeholder with a serial number, but careful not to overwrite records who already have a serial number on them.

The elements encased in the red box are evaluating if the shipped serial number is that of a hardware instrument or not. We want to stamp a serial number of an instrument only on the asset placeholder record.

The elements encased in the green block loop through the associated asset records and eliminate the records who have an established serial number to prevent them from being updated downstream. This way we don’t overwrite previously stamped information from an earlier shipment.

The elements encased in the blue block take the list of asset records without a serial number and the list of unmatched and recently shipped serial numbers and add them to a collection variable. Inside the collection variable, we’re updating other details such as shipment date, warranty information, and more. The final step: Update those asset records.

And we’re done!! To recap our business process and tools used:

• We first used MuleSoft Composer to update our Salesforce order record with details from the newly created NetSuite order record.
• We then used Flow to immediately create asset and order asset records to create placeholders to inform support teams of what was recently sold in order to plan ahead.
• Then we used MuleSoft Composer to update the Salesforce order records with shipment details once goods were shipped out of NetSuite.
• Lastly, we used Flow again to take the shipment details and update the correct and corresponding asset records with shipment details.

Tips for success

We had a lot of fun working with Flow and MuleSoft Composer to solve the business problem. Along the way, we learned a lot, and we’d like to pass those nuggets of knowledge forward for your success.

• Remember: Increasing user adoption is about simplifying the day-to-day workload and adding automation where possible.
• Choose the tool based on the need. In this solve, we used Flow to manage data already living in Salesforce, and we used MuleSoft Composer to mule data from system to system.
• Draw it out! Don’t be afraid to write out the business process and develop a data model from it. Often that’s the most challenging part and reduces risk of gaps existing in the final design.
• Lean on the community, Trailhead, and all the wonderful bloggers out there. In fact, part of the second flow showcased here was designed off a great blog post about how to take a text string and prepare it for an iterative loop evaluation.
• There’s always more than one way to solve the problem.
• Have fun.

Until next time, #AwesomeAdmins, happy Salesforcing!

Resources

• Salesforce Admins Blog: How to Write Great Documentation to Help with Future Problem Solving
• Salesforce Admins Podcast: Solving Business Problems with Composer and Flow with Jennifer Cole
• Trailhead: Get Started with MuleSoft Composer
• Trailhead: Build Flows with Flow Builder

Want to see more good stuff? Subscribe to our channel!