Leverage Flows To Process Inbound Emails With Documents | Automate This!

Business need

Some time ago, one of our customers at Praxis Solutions approached us with the following request.

We currently use a shared email inbox where all of our vendors send invoices to. We have several Account Payable (AP) associates who will claim an email, tag it with a color that represents them, and continue to process those for payment, including entering their details in our Salesforce-based accounting system. However, the process is severely lacking in our ability to track the progress of each invoice processing, as well as reporting on our associates’ efficiency. When an associate is out of the office, no one else has visibility into what he has done. Finally, for certain amounts, the invoice must be approved before being queued for payment. There must be a better way!

The solution

High-level process design

Here is the high-level design of our solution.

1. Vendors send invoices via email to a generic email address (for example, ap@company.com); the email is forwarded to a Salesforce Email Service.
2. The email service uses an Apex class that passes the email and other relevant information into a flow.
3. The flow is responsible for the processing logic:
   1. Create a record in a custom object called Inbound Invoice.
   2. Attach all files attachments to record.
   3. Send a receipt confirmation email to the vendor.
   4. Publish a notification to a queue of AP associates.
4. The AP associate reviews and processes the invoice, manually entering details as viewed in the invoice.
5. The AP associate invokes automation to create an Accounting System Accounts Payable Invoice.
6. Based on Aging Report review, the AP associate Processes Payment to Vendor.
7. A payment confirmation email is sent to the Vendor.
8. The payable record is marked as completed.

Step 1: Create a custom object to record the incoming invoice

Once the email is received, we need a place to store the email body and attachments, and to allow users to interact with the data. For this purpose, we’ll create a custom object named Inbound Vendor Invoice.

We will create fields to store email-related information, such as From Email and To Email, as well as Subject and Body. In addition, we’ll create the fields we expect our users to populate. In our example, these would be Vendor, Invoice Number, Invoice Amount, and so on.

Here are the Inbound Vendor Invoice object attributes.

Here are the associated fields.

Step 2: Install open-source packages

For this project, we’ll use two open-source components provided by Praxis Solutions.

1. Email to Flow
   This component is our focus here today. It includes an Apex class that will handle the email receipt and a flow that the Apex class will invoke. The sole purpose of the Apex class is to assign the incoming email data to variables, and then pass them into the flow. In our flow, we can implement whatever logic we need to handle the incoming emails.
2. PDF Viewer
   This Lightning web component can be placed on a Lightning page, and will display on-screen a tabbed window. A tab will be displayed for any PDF file attached to the record on which we place the component. In each tab we’ll see a preview of the PDF. This can be very useful when we need to see a PDF on the screen while recording information from it into Salesforce.

NOTE: By default, Salesforce may download the PDF files instead of presenting them on the screen. If you experience this, the solution is simple.

1. Navigate to Setup > File Upload and Download Security.
2. You’ll observe that the .pdf file’s 'Download Behavior' is set to 'Hybrid' (see screenshot below).
3. Click Edit.
4. Change the .pdf behavior to ‘Execute in Browser’.
5. Click Save.

Step 3: Create a queue and assign users

In our use case, we want to send a notification to a group of users when a record is received. We also want incoming records to not be assigned to any individual team member, but rather to a queue from which each user can ‘pull’ and assign records to themselves.

Note: Add the users you want to be part of the queue. During development and testing, only add the users you want involved in testing.

Step 4: Create the Lightning page

Note: When creating a Lightning page, it’s much simpler once at least one record exists in the org, so that sample data can be viewed. Without it, it can be more difficult to visualize what you’re building. Take the time to create one such record before starting this section.

Since our goal is to let users extract data from the PDFs attached to the emails, we’ll use the PDF Viewer component mentioned above.

Below is how I chose to organize the data using the Header and Right Sidebar. On the main section, we’ll place our PDF Viewer, and on the Sidebar, we can add a Tab component to organize our data. But to each their own when it comes to design.

I typically try to think of the following when building a Lightning page.

1. Keep the page organized and concise; too much data all at once tends to overwhelm users and reduces their adoption.
2. Consider using organization tools such as Tabs, Accordions, and Conditional Visibility to create a ‘landing page’ view where the user sees the most common or important information when the page loads, but still keeping it easy to find other information which may be required for the purpose of handling the record effectively.
3. Use Dynamic everything; leverage Dynamic Pages, Dynamic Actions, and Dynamic Related Lists to stay as far away as possible from ye-olde-page layouts.

What I ended up with looks like this.

Step 5: Create the email service

Now that we’ve created the object where we want the data to reside and the Lightning page, it’s time to set up our email service. An email service in Salesforce represents a channel to which emails can be sent and processed in a certain way.

Each email service can have more than one email address; however, all incoming emails to this service will always be passed to the same Apex class for processing.

To set up the email service:

1. Navigate to Setup > Custom Code > Email Services.
2. Click New Email Service.
3. Give the Email Service a Name; in our case we’ll use ‘Accounts Payable’.
4. For the Apex class, select EmailToFlow.
5. Set the Accept Attachments to ‘All’.
6. You can set up an allowlist to accept emails for; however, that would not be relevant for our use case, so we’ll skip it.
7. Select the Active checkbox.
8. Click Save and New Email Address.

Email Service

Email Service Address

1. For the Email Address Name, enter the API name for this address (so no spaces, special characters, etc.).
2. For the Email address, select something simple—your users will not actually use this email address. I’ll choose ‘ap’.
3. Leave the Active checkbox checked.
4. Select the Context User, the user that will be the one processing these incoming emails. Make sure that the user you select here has access to the EmailToFlow Apex class, as well as the Inbound Vendor Invoice we created.
5. Unless you only want to receive emails from your own email, clear out the Accept Email From text box.

Once you click Save, you’ll see the actual, very long email address that Salesforce assigned to the service.

We’ll typically work with whomever manages emails in our organization to create a @mycompany.com email address and forward it to this Salesforce address.

Step 6: Configure email-handling flow

The Email to Flow package includes a flow titled ‘Email to Flow Processor’, an autolaunched flow that’s invoked by the EmailToFlow Apex class when an email is received.

Let’s discuss what we want the flow to do in pseudo-code.

1. Confirm the logic will execute for emails received to the AP email address.
2. Check if there’s an existing Inbound Vendor Invoice (IVI) to attach the email to; otherwise, create a new IVI record, populating all of the email-related fields.
3. Create an Email Message record to attach to the IVI (found or created) record.
4. Store all Email attachments as files related to the IVI record.
5. Send notification to Accounts Payable Team in queue.
6. Send a reply message to Vendor, confirming receipt of the invoice.

This all seems pretty straightforward; let’s see how we implemented this.

Breaking down the flow, element by element

Step 7: Configure an Approval Process (optional)

If we need any approvals for invoices with specific vendors over certain amounts, or any other criteria, we can set up an Approval Process.

In our case, we have a submission action that updates the Status to ‘Approvals in Process’. When the Approval Process is complete, we update the Status to either ‘Approved’ or ‘Rejected’.

We’ve also set up validation rules and even conditional visibility to ensure that AP associates can’t proceed beyond a certain stage without the necessary Approval.

Step 8: Configure additional automation (optional)

Depending on your use case, you may want or need to create additional automation. For example, if you’re using a Salesforce-based accounting system, you may want to create the accounting ‘Payable’ records; a quick action with a flow can accomplish most of these activities. In our case, we also sent another email to the vendor at the time of completion, indicating that the invoice was processed and has been scheduled for payment, and that another email will be sent once payment is made.

Step 9: Rock 'n roll (test what you’ve built)

As always, before passing any functionality to your users to test, make sure that you test this robustly first, such as sending emails with no attachments, one attachment, and many attachments; sending emails with multiple ‘To’ addresses, 'CC' addresses, etc.

The more you test, the more likely it will be well received by your users and, by extension, adopted more fully.

Also, even if you feel you tested all possible scenarios, always have your users perform testing in a sandbox as well, before promoting to production.

Once you’re confident that testing uncovered no more issues, proceed with planning your production deployment.

Give this a try

There are always many different ways to solve a business requirement, and this one happens to be the way we elected to do this for our customer.

By leveraging standard Salesforce functionality—Email Services together with a custom Apex class—we’re able to empower declarative developers (aka Flownatics aka Salesforce Admins) to create new functionality altogether.

The mechanism of accepting emails and processing them using Flow has been reused by consultants at Praxis many times since, and even more specifically, the implementation with the PDF Viewer has found many other use cases. With this knowledge and tools at hand, your imagination is the limit.

I encourage you to install the packages and try this out in your org!

1. Email to Flow package
2. PDF Viewer package
3. UnofficialSF: Flow Screens and Actions*
   1. Get Group Info: https://unofficialsf.com/get-group-info-user-emails-and-more/

*Be aware that components and actions available on UnofficialSF are community built and have not gone through Salesforce security review. Your company may have policies you should consider before deciding to install any component that has not gone through security review into any of the company’s Salesforce orgs, whether production or sandboxes.

We always look for ways to empower our declarative developers to implement more functionality and custom solutions without needing to get developers involved. This allows us to be more flexible with what resources can be assigned to solve a task, but it also empowers declarative developers on projects where programmatic developers may not have been scoped or assigned to still implement extremely capable solutions.

I would love to hear what other use cases you found for this particular solution!

Hit me up on X or on LinkedIn.

Resources

• Trailhead: Platform Events Basics
• Trailhead: Platform Events Debugging
• Salesforce Help: Email Services

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