Online Application Best Practices

Before you Begin

Before you begin, we recommend testing in a Partial sandbox (with a maximum of 10,000 application records) or a Developer sandbox (Note: You must load your application records and Attachments).

Suppose you only have access to test in a Full sandbox. In that case, we recommend limiting the number of application records that generate snapshots to 10,000 (using data loader or some other means).

Criteria 

The criteria for generating Application Snapshots are as follows:

Reporting 

Salesforce has limited options for reporting on Attachment records. The following queries can be run in Dev Console to get an "upper bound" of the number of snapshots that can be generated if the service is enabled:

You can access the Developer Console from the Setup icon:

Total number of Application Records with application.json attachments:

SELECT Count(Id)
FROM Attachment
WHERE Name = 'application.json'

Total number of applications that meet the non-attachment criteria for Option 1:

SELECT Count(Id)
FROM TargetX_SRMb__Application__c
WHERE TargetX_SRMb__Stage__c = 'Submitted' AND
TargetX_App__Application_Process__c <> ''

Total number of applications that meet the non-attachment criteria for Option 2:
The status value is variable depending on the status selected on the Settings page and will need to be updated accordingly

SELECT Count(Id)
FROM TargetX_SRMb__Application__c
WHERE TargetX_SRMb__Status__c = 'Complete - Pending Review' AND
TargetX_App__Application_Process__c <> ''

Best Practices in dealing with Spam bots and manually submitted fake applications

Spam bots can create accounts using your Online Application, resulting in numerous invalid records in your Org. If you've already been hit by a Spam bot, you can clean up the invalid records manually; or,  if a large number of records were created, use a data tool, such as Informatica, to mass-delete the invalid records.

Best Practices to prevent Spam bots from infiltrating your system:

• Upgrade to at least the December' 1'19elease - this release contains an update to CAPTCHA, which will prevent spam bots from bypassing the CAPTCHA feature.
• Enable CAPTCHA.
• Create a Validation Rule to prevent spam records from being created

Validation Rule
If your spam attack is characterized by records being created that all have an email address ending in qq.com, a validation rule should prevent the spam records from being created.

This is a bit of a brute-force approach to preventing spam bot attacks. Remember that Validation Rules are not a perfect solution but are a helpful stop-gap measure while you work to implement CAPTCHA.

Create two identical rules:

• One on the User object
• One on the Contact object.

1. Go to Setup and search for Object Manager.
2. Locate the User or Contact(Student) object and click Validation Rules.
3. Click New.
4. Create a rule matching the following on each object:
   1. Rule Name = <client defined>, such as 'NoQQdotcomUsers'
   2. Error Condition Formula = CONTAINS(Email, "@qq.com")
   3. Error Message = <client defined>, such as 'New registrations are not currently being accepted from this email domain.'
   4. Error Location = Top of Page
5. Save your changes.
6. Repeat for each object (User, Contact/Student).

Note: This will prevent any legitimate students with a qq.com email from filling out an application. We recommend that you only implement this for a short time while you enable CAPTCHA.

Mass-delete invalid records
To clean up your data, you will want to use a data tool to do the following tasks:

• Set all spam User records to inactive by setting the values in the IsActive and IsPortalEnabled records to False.
• Run a report of created contacts and use a data tool or Informatica to delete the appropriate contact records.

Note: You will need to set the two validation rules to Inactive while performing these data cleanup tasks; you can reactivate them as soon as the data cleanup is complete.

If you don't have CAPTCHA enabled, we recommend doing so; the product solution in the December 19 release involves implementing CAPTCHA on your online application. Follow the instructions in the Knowledge article Configuring CAPTCHA for the Online Application.

Dealing with Fake Applications 

In addition to Spam-bots, Manual spamming can occur when a user fills out and submits online applications manually with false information.

The most important part of dealing with Manual spamming of applications is asking "W" at does someone gain from this?" "nlike computer-generated spam apps that are always probing for vulnerabilities wherever they can find them (and are kept at bay by CAPTCHA), people will only create fake applications if they stand to benefit from them. Thus, the way to prevent fake applications is to make it harder for a spammer to get what they want. Generally speaking, spammers target schools that use an auto-admit system that gives them something tangible just for being admitted. Some examples of this we've seen in the past:

• Automatic .edu email address:  .EDU addresses are valuable, largely for the free discounts many retailers and service providers apply to accounts created with or purchases made with such an address. Spammers will rapidly create apps to gather .edu email addresses and then either sell them or use them to buy products at a discount and resell them at full price.
• Automatic MS Office access: Some schools will also give access to the MS suite, which can be sold alongside the .EDU email.
• Automatic Financial Aid: Sometimes schools even distribute financial aid automatically based on admittance, which obviously is a target for someone trying to scam a school out of money.

In all these cases (and more) where something is gained for filling out an app, the answer is to revise business processes to remove the distribution of whatever is being targeted without a manual intervention or validation step. If spammers can't rapidly create the applications and receive whatever they're aiming for, the cost/benefit balance quickly swings away from them, and they will slow down or stop their attacks.
 

Suggested Updates to Business Processes 

Below are suggested updates for manual verification that you can make to your business processes to minimize the impact of Manual Spamming. These options will require you to update any Automated Auto-Accept workflows you currently have in place and manually verify new applications before any workflows are triggered.

Please be aware these changes will also affect your ‘real’ applicants. You’ll need to audit your Application emails to ensure applicants have the appropriate information based on your updated process.

Option 1: Create a checkbox on the Application object to be checked when an application has been manually verified. 

• This would require you to update your workflow(s) to include this checkbox in your filter (where the checkbox is unchecked) - True, False

Option 2: Create a separate Application Status or another custom field picklist value.

• This would require you to update your workflow to trigger off of the new picklist value.

Option 3:  You can do a combination of Options 1 and 2. In this case, your workflow would trigger when the checkbox and new picklist value have been updated.

• This would require you to update your workflow(s) to look for the new checkbox [unchecked] and then trigger off of the specific picklist value [Accepted].

Manual Verification 

Suggestions on what to look for when manually verifying applications:

• Look for duplicate values on same-day applications, such as:
  • Emails
  • Addresses
  • Birthdates 

Note: The most common cases of manual spamming Applications occur on the same day.

Other recommendations:

• Consider charging an Application Fee
• Do not include the .edu email address in your Acceptance process. You can share this after you have verified the applicant’s intent to matriculate.

Setting up the TargetX Online Application and/or Portal after refreshing a Sandbox

This article assumes the sandbox was recently refreshed and/or created from a production environment where the Online Application is installed and configured and need to ensure it can be used and tested fully in the sandbox.  This article does not provide instructions on creating a new application in the sandbox. If you are testing Application Snapshots, please review this article for Best Practices: Best Practices for the Setup and Testing of Application Snapshots.