Register people receiving your program's support with consent on record

What happens after someone submits

The field table below separates identity, requested support, and consent because those answers serve different operational decisions. Staff first need to know who has requested help. They then need to understand which services may fit. Consent must remain visible when someone accesses or exports the record.

A new submission appears in the submission dashboard, where staff can review it before beginning a case. This avoids treating every request as an approved enrolment. A program may need to check eligibility, capacity, location, referral criteria, or documentation before it confirms support.

You can also respond immediately through Laravel. The listener below reads the submitted name, requested services, and data-consent value. It writes a structured intake event that an existing casework workflow can use to notify the assigned caseworker or create a review task.

<?php

namespace App\Listeners;

use FilaForms\Core\Events\FormSubmitted;
use Illuminate\Support\Facades\Log;

final class RouteBeneficiaryIntake
{
    public function handle(FormSubmitted $event): void
    {
        $data = $event->submission->data;

        Log::info('Beneficiary intake received', [
            'form_id' => $event->form->getKey(),
            'submission_id' => $event->submission->getKey(),
            'full_name' => $data['full_name'] ?? null,
            'services' => $data['services'] ?? null,
            'data_consent' => $data['data_consent'] ?? null,
        ]);
    }
}

Laravel 12 discovers listeners in app/Listeners automatically. Keep the listener small and send its structured intake data into the same queue, case-management record, or review process that your staff already trusts. This keeps the form focused on collection and keeps routing rules close to the service workflow.

Routing a new beneficiary to a caseworker

Route new intakes by a rule your program can explain. A local program can assign by service area. A specialist program can assign by requested service. A smaller team can send all new records to one intake queue, then let a coordinator distribute work during regular triage.

The submitted services value should support routing, not replace human judgement. Someone may select several needs, and the right worker may depend on urgency or capacity. Store the original answer with the submission so staff can see why the routing rule chose a queue.

Give the receiving caseworker enough context to make a first contact safely. The person's name, selected services, and consent status provide a useful minimum. Avoid placing extra sensitive details into emails or broad chat channels. Link staff to the protected record instead when they need the full intake.

Only 12% of nonprofits describe themselves as digitally mature, according to the Salesforce Nonprofit Trends Report, 5th edition, 2022. A defined intake route helps a program make its first operational improvement without requiring a full case-management replacement.

Adapting this template for household-based programs

Household-based programs often make support decisions from shared circumstances rather than one person's request. Add a household size field when household composition changes eligibility, benefit limits, food allocation, or appointment planning. Keep its meaning clear, such as whether it includes the submitting person.

Use the household size in an eligibility check after submission. A field alone cannot decide eligibility because programs also apply local rules, funding conditions, and staff review. Put that decision in the workflow that already owns your program rules, then record the outcome alongside the intake.

Some programs never send outreach communications. Remove marketing consent in that case, so the form asks only for permissions your organization actually uses. Fewer unnecessary questions can make the consent section easier for participants to understand and for staff to administer.

If the program serves people through a representative, define who can submit on another person's behalf. You may need a relationship field or a separate authorization process. Do not infer that authority from a name alone.

Handling consent responsibly

The consent section should explain the specific data use before a participant submits the form. Staff should be able to see the recorded consent status during follow-up. That makes it less likely that a service interaction relies on an assumption made outside the intake record.

Capturing data_consent on submission is not a full compliance program. Your organization still needs its own retention policy and a way to honor consent withdrawal. Those processes determine how long data stays available, who can access it, and what changes when a participant withdraws consent.

Treat consent withdrawal as a workflow event, not a note that disappears in a record. Identify the person, update the relevant permission, stop the affected use, and retain only what your policy requires. Review any exports, mailing lists, or connected systems that may have received the earlier consent state.

When this template is the wrong tool

This template is not enough when your organization needs a complete compliance program. It records an intake consent decision, but it does not create your retention policy or perform consent-withdrawal handling. Define those responsibilities before collecting sensitive beneficiary information.

It also needs adaptation when the program has a formal eligibility assessment, complex household relationships, or referrals across several agencies. Begin with this intake as the registration point, then connect it to the controlled review process that makes the final service decision. For broader form workflows, review the Filament form builder features.