• Michael Kolodner

FormAssembly Errors to Cases


One of the most important things I do with FormAssembly is make sure that when there are errors sending data to Salesforce we don’t lose track of those problems. That was important for me as a solo admin but it's perhaps even more important as a consultant supporting multiple organizations.


When there is a connector error you want to make sure that the right person in your organization sees it and can deal with the problem. Sometimes you might even want to be able to assign different kinds of errors to different people, either by which form they come from or based on some other criteria.


And you want to be able to document and report on how you or your team are ensuring that the data coming from FormAssembly is working right.


There’s a really convenient way to set this up: Email-to-Case.


Email-to-Case is a standard Salesforce feature that allows messages to a particular email address to automatically become case records in Salesforce. It’s very easy to set up and doesn’t require any extra licensing for nonprofits on the P10 donation. Once email-to-case has created a record you can use all the other features of Cases, including setting up rules for who is assigned the case, tracking them through stages until they are completed, collaborating via Chatter, etc.


Many organizations don’t use cases because they aren’t engaged in customer service type support, so the object is just sitting unused. This makes it perfect for collecting and organizing your FormAssembly connector errors! But if you’re also using Cases for other things, it’s certainly possible to use it for FormAssembly at the same time.


Here are the steps to get yourself set up to monitor FormAssembly errors via Case:


1. Set FA to send alerts to someone in the organization.

This is probably the most important step. In fact, even if you aren’t using email-to-case, make sure you follow this instruction!


New accounts ought to be set up this way by default, but that isn’t always the case. I have alerted FormAssembly Support to this problem but I’m not sure if it’s fixed yet. (I haven’t created a new FA account in a little while.)


In your FormAssembly account, go to your profile>General Settings and check “Notify me of any downtime or processing error regarding my forms.”

screenshot from FormAssembly settings of the checkbox for getting form errors

As I said, this ought to be checked by default. If it’s not, then when a form has an error, it fails silently. Yikes!


With the box checked, the FormAssembly account user is going to get emails whenever there is an error that prevents a connector from sending data to Salesforce.

(Note: If you have an Enterprise FormAssembly account with multiple logins the errors will go to each form’s owner. You’ll need to tweak the instructions here to account for that difference or else set all forms to send their errors to the same person.)


Of course, if you’re the form builder and the Salesforce admin, you might just figure getting those emails is enough. You can see them in your In Box and deal with them when they occur. But perhaps you like to go on vacation? Or perhaps you’re the form builder but not the FormAssembly account holder, so the emails don’t go to you? Also, using your In Box as your To Do List is not necessarily the most convenient for all sorts of reasons…


2. Make An Error Form

In order to test our setup and to help us as we build it, we’re going to make a FormAssembly form whose entire purpose is to cause errors when it’s submitted. (It should be obvious that we’re never going to share a link to this form to anyone else.)


I literally name my form “Exists only to trigger connector errors.” That way I feel there’s little likelihood of someone misunderstanding how this form is used. It’s a pretty simple form, too. Basically it just has a submit button:

You can set up the connector in all sorts of ways. (It’s not that hard to figure out something that will fail.) Here is an example of trying to find and then update a contact with no last name. Because Last Name field is always required for a contact in Salesforce, this is guaranteed to fail.

A FormAssembly to Salesforce connector that is guaranteed to error: update a contact where Last Name = ""

Now test out your form to make sure that you get an email about the connector error. (If you’re not the one error emails go to, warn your colleague that this error is on the way. It might be helpful for them to forward it on to you.)


3. Set up On Demand Email-to-Case

In Salesforce go to Setup>Service>Email-to-Case.

Check Enable Email-to-Case and Enable On-Demand Service.


Then click New under Routing Addresses.

  • Give a name (your choice).

  • Put in the email addresses you want to accept cases from. For this purpose, we need to accept from support@formassembly.com and from the email address we’re going to forward errors from (yours, or the FormAssembly account holder’s). [See the note in the next section that you might also need to accept from a temporary verification address.]

When you click save, you’ll get an Email Services Address that is the name you gave plus a long string of characters. That’s the address you’re going to send emails to that will result in cases.


You can try this: Send an email to that address. Load the Cases tab and see that a new case has been created.


4. Set Up Email Forwarding

Whoever is now receiving the error emails now needs to set up their email account to forward those error emails to the Salesforce email-to-case address that you just created.

Specific instructions for setting up forwarding rules vary by your email provider, so they’re outside the scope of this post. But it’s generally pretty easy to figure out. You just set a rule that all emails like the one you triggered from FormAssembly should automatically be forwarded to the email-to-case address (and probably immediately removed from the In box, since you’re going to be keeping track of them elsewhere).


One thing I’ve learned the hard way: If you want to set Gmail to forward you have to first send a verification email to the account you’re going to forward to. That verification email will come from forwarding-noreply@google.com, not from the person/account that will be doing the forwarding. (It took some frustrating hours to realize that!) So when you’re setting up which addresses Salesforce should accept email-to-case from (Routing Addresses), you have to watch for that email. Once you get the forwarding set up, the messages will come from the original sender (support@formassembly.com).


Now, you should be able to trigger an error from your errors form and see that a case gets created in Salesforce. Voila!


Theoretically you’re done now. But you might notice that the case subject is pretty generic. We can do better than this! Let's see how to make these cases a little easier to work with.


5. Set up cleaning up of the case when it’s created

The case created by email-to-case is going to be pretty generic because the FormAssembly error emails always have the same subject, like this:

FormAssembly / Salesforce Connector Error Report - 06/12/2022 01:45:49 PM


The body of the email tells you the name of the form and has a link to the response that errored. But it would be nice if your case had the form name in the Subject so you could easily distinguish them, wouldn’t it?


Flow to the rescue! We’re going to build a simple Salesforce Flow that runs whenever a Case is created and is set for Fast Field Updates (which means it runs Before Save).

A flow with three components: a Decision and then two Assignments

The first thing this flow does is check to see if the case subject contains “FormAssembly / Salesforce Connector Error Report,” to know if we need to do the other steps.


Then it’s going to replace the subject with a formula that parses the email body to find the name of the form that triggered the error:

/*Give me a section from the middle of the Description field*/

MID({!$Record.Description},

/*starting 11 characters past the first character of the substring "your form "*/

FIND("regarding your form ",{!$Record.Description}) + 21,

/*and ending just the right number of characters later. 22 leaves a quotation mark. So do any other numbers I've tried, so we'll just have an extra step to remove that quotation mark. */

(FIND("WHAT HAPPENED",{!$Record.Description}))-

(FIND("regarding your form ",{!$Record.Description}) + 22)

)


Then the final step is to clean up the text of the subject because the all-text email has some Unicode instead of characters, like "&#41" instead of ")". This step also grabs the link to the FormAssembly response and puts it into a URL field we’ve created on Case.


I use five formulas for this. They’re a bit of a pain to read if you’re not familiar with Salesforce formulas, but you could just copy/paste and they’ll work:

Assignment flow component that sets five field values.

Here’s the formula for formulaFormResponseURL

/*Give me a section from the middle of the Description field*/

MID({!$Record.Description},

/*starting 2 characters past the first character of the substring "The following response was received, but could not be processed using the Salesforce Connector:" which is 95 characters long*/

FIND("The following response was received, but could not be processed using the Salesforce Connector:",{!$Record.Description}) + 96,

/*and ending just the right number of characters later https://powerofus.force.com/0D58000002e7nDy?fromEmail=1&s1oid=00D00000000hWLM&s1nid=0DB800000004Fa7&s1uid=00580000009bjBJ&s1ext=0&emkind=chatterCommentNotification&emtm=1461274144137&OpenCommentForEdit=1 */

(FIND("The error was:",{!$Record.Description}))-

(FIND("The following response was received, but could not be processed using the Salesforce Connector:",{!$Record.Description}) + 97)

)


Here’s formulaRemoveExtraQuoteInSubject:

SUBSTITUTE({!$Record.Subject} , '"', '')


And here’s formulaReplaceCloseParenInSubect:

SUBSTITUTE({!$Record.Subject} , "(", "(")

[The formulas for for OpenParen and Hyphen are the same as CloseParen but use &#41 and &#45, respectively.]


6. Set up a case assignment rule to assign cases to the right person/people

Now that you have a case that’s organized and readable, you can set up a case assignment rule. Of course, if you’re a solo admin and the sole form builder, you might just assign all cases to yourself.

A default case assignment rule that assigns all cases to Michael Kolodner.

But as your organization grows or others learn to work with FormAssembly you can use Salesforce’s standard case assignment rule functionality to share cases among a larger team.




7. Set up a case assignment email template

I tend to assume that people (including myself) won’t remember to go looking for cases without a reminder. So you can set Salesforce to send an email to the case owner whenever there is a new case. The first step in that is making an email template. It doesn't have to be anything fancy, just the most pertinent fields (Subject, Status, Description)

An email template that merges in case fields.

This email is going to go out to remind you (or whoever gets form cases) that you have a form error case to deal with. But because we have also created the case, this email is not the only record of the problem. Someone else could look in on cases to see what errors are still unsolved.


8. Set up a case assignment email alert

Then use that email template in an email alert.

An email alert using the Case Assigned email template.

9. Have flow send an email

Finally, set a Flow that will send out that email alert to the case owner upon the creation of a case.


97 views

Recent Posts

See All