---
title: "Prevent Duplicate Application Submissions Based on Application Data"
slug: "preventing-duplicate-application-submissions-based-on-application-data"
status: "new"
updated: 2026-06-02T17:01:59Z
published: 2026-06-02T17:01:59Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.technolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Prevent Duplicate Application Submissions Based on Application Data

> [!NOTE]
> 📚 Part of the series **Application Building Phase II:** [**The Slate-hosted Application**](/v1/docs/introduction-to-the-slate-hosted-application)

You can create an [application submission requirement](/v1/docs/submission-requirements-hard-and-soft-fails) 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.

![](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/Subquery filter - Exists - Another submitted application with the same entry term and major.png)

## 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.

> [!WARNING]
> 📝 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:

| Filter | Purpose |
| --- | --- |
| Join: Person | Moves from the current application to the applicant's person record. |
| Join: Person / All Applications | Accesses all applications on the same person record. |
| Comparison - GUIDs not matching | Confirms that the joined application is not the current application. |
| Comparison - Entry Terms Match | Confirms that the current application and joined application have the same entry term. |
| Comparison - Programs Match | Confirms that the current application and joined application have the same program, major, or other selected program field. |
| All Applications / Submitted Status = Submitted | Limits the match to another application that has already been submitted. |

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

| Comparison | Field 1 | Operator | Field 2 |
| --- | --- | --- | --- |
| Current application is not the joined application | Application GUID | `!=` | All Applications GUID |
| Entry terms match | Current application entry term | `=` | All Applications entry term |
| Programs match | Current application program, major, or equivalent field | `=` | All Applications program, major, or equivalent field |

Here’s how the end result looks:

[![](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/10800874010779.png)](https://cdn.us.document360.io/cd8ea7a6-07f3-4846-a554-627ac016d3e3/Images/Documentation/10800874010779.png)

## 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](/v1/docs/submission-requirements-hard-and-soft-fails)
- [Access and Submission Conditions](/v1/docs/access-and-submission-conditions)
- [Require Custom Fields](/v1/docs/require-custom-fields)