Triggers

How state PTAs use triggers to automatically generate compliance and governance activities across units, councils, and districts.

What Is a Trigger?

A trigger is a rule defined at the state level that automatically generates activities (tasks) for units, councils, or districts on a schedule you define. Triggers are the engine behind recurring compliance work in FutureFund Connect — things like annual financial reports, insurance renewals, bylaws reviews, and mid-year audits.

Each trigger answers three questions:

  1. Who does the activity apply to? (unit, council, or district)
  2. When should the activity be created?
  3. When is the activity due?

Triggers live in State → Triggers and flow down through the hierarchy to generate activities in the appropriate entities.

Triggers are an advanced feature. If you aren’t sure how to configure one, reach out to FutureFund Support.


Core Concepts

Applied-To Entity

Every trigger targets one of:

  • Unit — activity is created for each available unit under the state
  • Council — activity is created for each available council
  • District — activity is created for each available district

Only entities in the available status receive activities from triggers.

Starts On

An optional floor date. A trigger will not create activities with a creation date earlier than Starts On. Use this to schedule a new trigger to begin running in a future fiscal year without affecting the current year.

Allow Manual Trigger

When enabled, authorized users can manually fire the trigger to create an activity on demand, in addition to (or instead of) the automatic schedule. Combine this with the Manual creation strategy (below) for triggers that should only run on demand.

Inclusion & Exclusion Criteria

Both fields accept Liquid templates that evaluate against the candidate entity. The trigger runs for an entity only when:

  • Inclusion criteria is blank or evaluates truthy, and
  • Exclusion criteria is blank or evaluates falsy

Examples:

{# Inclusion: only units that have adopted bylaws #}
{{ entity.last_bylaw_on | date: "%s" | plus: 0 }}
{# Exclusion: skip units whose fiscal year ends in December #}
{% if entity.fiscal_end_month == 12 %}true{% endif %}

Blueprint

The JSON Blueprint defines the resulting activity — its description, activity type, routing chain, followers, and optional file generator. This is the “template” that gets stamped out for each matching entity when the trigger fires.

De-duplication

Once a trigger creates an activity for an entity within a given cycle window, it will not create another for that same entity in that same cycle. The window is determined by the creation strategy:

  • Calendar — the calendar year of the activity’s creation date
  • Fiscal — the entity’s fiscal year containing the creation date
  • Anniversary — the N-year anniversary interval starting at the creation date

This means you can safely re-run processing without producing duplicates.


Creation Date Strategies

The creation date strategy controls when a new activity is created for each matching entity. Pick the one that matches your real scheduling rule.

1. Manual

The trigger never fires automatically. Activities are created only when a user manually triggers it (requires Allow Manual Trigger).

Use when: the event is ad hoc — e.g., “on request, create a special audit activity.”

2. Calendar

Fires once per calendar year on a fixed Month + Day.

  • Creation Month — 1–12
  • Creation Day — 1–31 (Feb 29 safely falls back to end of month in non-leap years)

Examples:

Scenario Month Day
Tax filing reminder on Jan 15 1 15
Summer leadership transition on July 1 7 1
Bylaws review every June 15 6 15
Year-end financial review on Dec 31 12 31

3. Fiscal

Fires once per entity fiscal year, offset from the entity’s fiscal year end.

  • Creation Fiscal Offset (Days) — negative for before fiscal year end, positive for after

Examples:

Scenario Offset
Start annual audit 30 days before fiscal year end -30
File annual report 60 days after fiscal year end 60
Final financial review on fiscal year end 0
Insurance renewal 90 days before fiscal year end -90

Because this uses each entity’s own fiscal calendar, units with different fiscal years are handled correctly automatically.

4. Anniversary

Fires every N years on the anniversary of a specific entity date.

  • Anniversary Source — either Last Bylaw Update (last_bylaw_on) or Organization Date (organization_on)
  • Anniversary Interval (Years) — 1 or more

Examples:

Scenario Source Years
Bylaws review every 3 years Last Bylaw Update 3
Bylaws review every 5 years (per PTA standard) Last Bylaw Update 5
10-year anniversary celebration reminder Organization Date 10
Annual re-affirmation on organization date Organization Date 1

If the source attribute is blank on an entity, the trigger will skip that entity.


Due Date Strategies

Once an activity is created, the due date strategy determines when it’s due.

1. Relative (default, legacy)

Due date = activity creation date + the first route’s Due In Days. This is the original behavior from before date strategies existed.

Use when: routing chains already encode “due X days from creation” and you want to keep that behavior.

2. Calendar

Due on a fixed Month + Day. If that date has already passed relative to the creation date, it rolls to next year.

  • Due Month — 1–12
  • Due Day — 1–31

Examples:

Scenario Month Day
Every activity due on April 15 (tax day) 4 15
Due by October 1 each year 10 1

3. Fiscal

Due date = entity’s fiscal year end + Due Fiscal Offset (Days). If the resulting date is before the creation date, it rolls to the next fiscal year.

Examples:

Scenario Offset
Due on fiscal year end 0
Due 30 days after fiscal year end 30
Due 15 days before fiscal year end -15

Putting It Together: Recipes

Below are common real-world patterns. Each combines an applied-to entity, creation strategy, and due strategy.

Annual 990 Filing Reminder (Fiscal + Fiscal)

  • Applied to: Unit
  • Creation: Fiscal, offset 1 (day after fiscal year ends)
  • Due: Fiscal, offset 135 (IRS deadline ≈ 4.5 months after fiscal year end)

Insurance Renewal — 60 Days Before Year End (Fiscal + Fiscal)

  • Applied to: Unit
  • Creation: Fiscal, offset -60
  • Due: Fiscal, offset 0

Mid-Year Audit (Calendar + Relative)

  • Applied to: Unit
  • Creation: Calendar, Month 1, Day 15
  • Due: Relative (use route’s due-in-days, e.g., 30 days)

Bylaws Review Every 5 Years (Anniversary + Calendar)

  • Applied to: Unit
  • Creation: Anniversary, Source Last Bylaw Update, Interval 5
  • Due: Calendar, Month 6, Day 30

Board Transition Kickoff on July 1 (Calendar + Relative)

  • Applied to: Council
  • Creation: Calendar, Month 7, Day 1
  • Due: Relative, 14 days (first route)

Ad-Hoc Special Investigation (Manual)

  • Applied to: Unit
  • Creation: Manual
  • Allow Manual Trigger: ✓
  • Due: Relative, first route’s due-in-days

How Processing Works

A background job processes triggers on a regular schedule. For each non-manual trigger:

  1. Gather all candidate entities of the right type (units/councils/districts) in available status under the state.
  2. For each candidate, evaluate Inclusion and Exclusion criteria.
  3. Compute the entity’s target creation date using the creation strategy.
  4. Skip the entity if:
    • The creation date is in the future (will try again on a later run)
    • The creation date is before the trigger’s Starts On
    • An activity from this trigger already exists in the current cycle window for the entity
  5. Otherwise, create the activity from the Blueprint, set its due date using the due strategy, assign the first route, and notify followers.

What Users See

When a trigger fires for an entity, the affected users (routing assignees and followers) receive notifications, and the activity shows up in that entity’s task list.


Legacy Frequencies

Triggers used to be configured with a fixed frequency (monthly / quarterly / semi-annually / annually). Those have been replaced with creation and due date strategies.

Existing triggers were migrated automatically:

  • Recurring frequencies → Calendar creation strategy keyed off the original Starts On month/day
  • No FrequencyManual creation strategy

No action is required for existing triggers, but we recommend reviewing each one to see whether a Fiscal or Anniversary strategy would better match your intent.


Tips & Best Practices

  • Start with Starts On. Setting a future start date is the safest way to preview a new trigger without generating activities immediately.
  • Prefer Fiscal for financial compliance. Units often have different fiscal years — fiscal strategies handle this automatically.
  • Prefer Anniversary for governance cycles. Bylaws and organization dates vary by unit; anniversary strategies schedule off each unit’s own date.
  • Use Inclusion/Exclusion to scope pilots. Roll out a new trigger to a single council first, then broaden.
  • Blueprint is JSON. Keep a library of known-good blueprints; small JSON errors will prevent the activity from being created.
  • Allow Manual Trigger is additive. You can combine it with any scheduled strategy to give staff an “emergency fire now” option.

Need Help?

Triggers are powerful but intricate — especially the Blueprint and Liquid criteria. When in doubt, reach out to FutureFund Support and we’ll help you get the rule right.


Was this helpful?