Welcome Alliance Fund Application Workflow Rebuild

Context

The Welcome Alliance Fund supports initiatives that improve arrival and participation for refugees and newcomers. It was created after Russia’s full-scale invasion of Ukraine in April 2022. Work with partners across government, business, philanthropy, and civil society highlighted the need for fast and crisis-resilient funding instruments.

The previous setup created friction for applicants and fund managers. Multiple forms caused confusion. Several Tally fields did not match HubSpot data types. Some critical emails did not reach applicants due to marketing permission rules. Automations had grown over time with little documentation.

Why it matters: Clear intake and reliable notifications protect applicant trust and reduce operational overhead.

Problem

The following issues caused most failures and confusion.

1. Form sprawl and misconfiguration: Applicants saw several similar forms. Many Tally fields used the wrong data types. This led to validation errors and poor downstream data quality.
2. Fragmented intake: The fund offered five funding options. Each had its own form. Applicants first had to know which option fit their case.
3. Email deliverability gaps: HubSpot blocked sends when contacts did not complete double opt-in for marketing. Operational notifications sometimes failed.
4. Legacy automations with low documentation: Workflows evolved piecemeal. Owners changed. Institutional memory was thin, which made safe changes difficult.
5. Unreliable mapping: The system used the applicant’s email as the identifier. Multiple submissions from the same person caused collisions between first and advanced applications.

Why it matters: Bad inputs create rework. Missed emails stall applications. Unclear processes cause confusion and frustration.

Approach and Process

I shipped in small increments and verified each step before scaling it:

1. Audit and map: I cataloged forms, workflows, triggers, and email paths. I corrected Tally field types across all active forms.
2. Prioritize by impact and risk: I focused on typed inputs, a unified intake, a canonical Application ID, and one parameterized workflow.
3. Iterate safely: I released changes in small batches. I monitored submissions and logs. I fixed edge cases quickly.
4. Align stakeholders. Requirements changed during implementation. I kept a regular cadence with fund managers. I interviewed former role holders to recover the reasons behind older design choices.

Why it matters: Small, iterative changes reduce risk in live systems and keep operations stable.

Solution

A. Single dynamic intake

I introduced one single Tally form for the first application for all application types. Applicants select one of five funding options. Conditional logic adapts the questions. I corrected field types across forms. I set required flags and file constraints where needed.

• Before: 5 first application forms and 3 advanced forms.
• After: 1 first application form and 1 advanced form.

Why it matters: One entry point reduces confusion. Typed inputs prevent many downstream errors.

B. One unified workflow in HubSpot

I collapsed five separate workflows into one parameterized workflow that covers all five offers. I standardized naming, properties, and transitions. I added clear comments and grouping inside the workflow.

Why it matters: One workflow is easier to reason about and maintain. It reduces failure modes.

C. Canonical Application ID

I replaced email‑based matching with a Ticket‑ID based Application ID. I shared this ID with applicants for support and follow‑up. The ID flows through all steps and communications.

Why it matters: Applicants can submit multiple times without record collisions. Operators can track each case reliably.

D. Stage safety with explicit triggers

I introduced four trigger properties for critical stage transitions. These properties make transitions intentional and auditable. They also reduce accidental moves.

Why it matters: Clear gates prevent human error and speed troubleshooting.

E. Reliable transactional email with MailerSend

I moved transactional emails to MailerSend. I log events back to HubSpot so teams keep one source of truth. Community and fund managers can receive MailerSend access and edit templates directly.

Why it matters: Critical notifications arrive even when HubSpot marketing permissions block sends. Teams retain visibility without duplicating tools.

F. Orchestration with Zapier

I used Zapier to connect Tally, HubSpot, and MailerSend. I standardized property updates and logging. I kept each Zap simple and well named.

Why it matters: Declarative integrations speed delivery. They remain transparent for future maintainers.

Results

• Fewer forms: First application forms went from 5 to 1. Advanced forms went from 3 to 1.
• Simpler operations: Five workflows became one parameterized workflow. Ownership and debugging got easier.
• Fewer submission errors: Field type corrections and a single intake reduced avoidable errors significantly.
• Better deliverability for critical emails: Transactional messages moved to MailerSend. Messages are logged to HubSpot for a complete history.
• Clearer record linkage: The Application ID removed confusion when people submitted multiple applications.

Why it matters: The process became easier to use and easier to maintain. It did not save much processing time per case. It did remove complexity and uncertainty for applicants and staff.

Challenges and Trade‑offs

• Legacy systems and low documentation: I reverse‑engineered the setup. I added guardrails and comments.
• Changing requirements: I shipped small improvements. I chose flexible, parameterized logic over one‑off fixes.
• ESP migration: Moving to MailerSend required new routing and logging. I kept HubSpot as the system of record to avoid data silos.
• Temporary coexistence: I kept some legacy elements during the transition. This avoided disruption while teams adjusted.

Lessons and Next Steps

• Institutional memory is critical: I asked former role holders to explain the original constraints. This saved time and prevented regressions.
• Design for change: Parameterized workflows, explicit IDs, and typed inputs handle evolving policies well.
• Next steps I would consider: Automated health checks for failed sends and orphaned tickets. A small dashboard for cycle time and deliverability. Light runbooks for new owners.

Project Details

• Timeline: June 2025
• Role: Project lead and sole technical implementer
• Collaborators: Fund management team
• Tech Stack: HubSpot, Tally Forms, Zapier, MailerSend, Miro