Prevent Duplicate Application Submissions Based on Application Data

📚 Part of the series Application Building Phase II: The Slate-hosted Application

You can create an application submission requirement to prevent an applicant from submitting the current application when another submitted application on the same person record already matches specific application data. If you allow multiple applications in a single round but don't want applicants applying to the same program multiple times, you can use this hard fail to prevent that.

This article uses entry term, program, and major as the example duplicate criteria. You can replace those comparison filters with the application-scoped data points that define a duplicate in your process.

Before you begin

• Decide which application data should define a duplicate application. Common examples include entry term, round, program, major, or an application-scoped custom field.

• Plan the applicant-facing warning text for the submission requirement. A hard fail prevents submission until the applicant resolves the issue or a staff member changes the underlying data.

• Build and test the logic in an inactive application logic record before activating it for applicants.

Creating the submission requirement

1. Go to Database → Application Logic.

2. Select Insert.

3. Configure the application logic record:    

   • Status: Inactive while you build and test the requirement

   • Type: Submission Requirement

   • Section: Select the Review page or the application section where the requirement should appear

   • Name: Enter applicant-facing warning text, such as You have already submitted an application for this program and entry term

   • Warning: Hard Fail

   • Base: Configurable Joins - Application

4. In the Filters section, select Subquery Filter.

To access data from all applications, you’ll create a subquery filter that joins from the current application to the applicant’s record, then to all of their existing applications.

Nested comparison filters between Application and All Applications determine that the overall filter looks for instances where a different, submitted application exists on the person's record, for the same entry term, with the same program selected.

Building the duplicate-application subquery

The outer subquery checks whether another submitted application exists on the same person record. It must join from the current application to the person record, and then from the person record to all applications on that person record.

1. Configure the subquery filter:    

   • Status: Active

   • Name: Enter a descriptive name, such as Exists - a submitted application with the same program and entry term

   • Type: Dependent subquery

   • Aggregate: Exists

2. Select Join, and then join to Person.

3. Select Join again, and then join from Person to Applications.

4. Name the joined applications relationship All Applications. This name distinguishes the joined applications from the current application being evaluated on the Review page.

📝 Note

The All Applications join includes the current application and the applicant's other applications. Add the GUID comparison below so the requirement compares the current application to other applications, not to itself.

Excluding the current application

Add a nested comparison subquery that returns true only when the current application GUID does not match the joined application GUID.

1. Inside the duplicate-application subquery, select Subquery Filter.

2. Configure the nested subquery filter:    

   • Status: Active

   • Name: Comparison - GUIDs not matching

   • Type: Dependent subquery

   • Aggregate: Comparison

3. Add an export for Application GUID. This export represents the current application.

4. Add an export for All Applications GUID. This export represents the application reached through the All Applications join.

5. Configure the comparison:    

   • Field 1: Application GUID

   • Operator: !=

   • Field 2: All Applications GUID

6. Select Save.

Matching the application data

Add a nested comparison subquery for each application data point that should match between the current application and the joined application. Each matching comparison uses the = operator.

For example, to block duplicate applications with the same entry term:

1. Inside the duplicate-application subquery, select Subquery Filter.

2. Configure the nested subquery filter:    

   • Status: Active

   • Name: Comparison - Entry Terms Match

   • Type: Dependent subquery

   • Aggregate: Comparison

3. Add an export for the current application's entry term, such as Application Application - Entry Term.

4. Add an export for the joined application's entry term, such as All Applications Application - Entry Term.

5. Configure the comparison:    

   • Field 1: The current application's entry term export

   • Operator: =

   • Field 2: The joined application's entry term export

6. Select Save.

Repeat this process for each additional duplicate criterion. For example, add another comparison subquery that checks whether the current application's program or major matches the same field on the joined application.

Requiring a submitted matching application

Add a filter on the joined application so the requirement only blocks submission when the matching application has already been submitted.

1. Inside the duplicate-application subquery, select Filter.

2. Select All Applications / Submitted Status.

3. Set the filter to Submitted Status = Submitted.

4. Select Save.

Reviewing the completed filter logic

The completed duplicate-application subquery should include the following filters:

At a configuration level, the comparison filters should use these operators:

Here’s how the end result looks:

Testing and activating the requirement

1. Select Save to save the duplicate-application subquery.

2. Select Save to save the application logic record.

3. Test the same filter logic in an application-based query before activating the requirement. Use Preview Results to confirm that the query returns only current applications that have a different, submitted application matching the duplicate criteria.

4. Test at least one application that should be blocked and one application that should be allowed to submit.

5. When testing is complete, return to the application logic record, set Status to Active, and select Save.

Adapting the pattern

Keep the GUID comparison and submitted-status filter in place whenever you adapt this pattern. Change only the matching comparison filters that define what counts as a duplicate for your process.

For example, you might compare round instead of entry term, compare a custom application field, or require multiple fields to match before the hard fail appears. The outer Exists subquery returns true only when all of the nested comparisons and filters are true for another submitted application on the same person record.

Further reading

• Introduction to Application Submission Requirements

• Access and Submission Conditions

• Require Custom Fields