Participant Request Center · add-on in design
A case manager asks a participant for a pay stub, a lease, a signed consent. The participant sends a blurry photo, it is rejected, and the thread is lost in text messages. The Request Center gives the participant one link on a phone that shows what is still needed, why an item was sent back, and the receipts staff chose to share.
A participant request workflow for case-managed programs: housing, benefits navigation, workforce, family support. It runs inside Salesforce, on top of the AutoSurvey Document Request add-on.
What it does
Staff see seven item statuses inside Salesforce. The participant sees four plain words. Each request item lands in one of them.
Staff asked for it. Nothing sent yet.
The participant taps the item and takes a photo or picks a file on the phone.
Received. Staff have not decided yet.
The participant sees the date it was received and does not need to send it again.
Rejected, with the reason in plain words.
"Out of date", "cut off", "wrong document". One step to send a replacement for that item only.
Accepted or waived.
If staff shared a receipt, such as a signed consent, the participant can download it after a one-time code.
Why it is useful
The participant taps a link in an email or text. The link is scoped to one program enrollment, expires on a date staff set, and can be revoked or reissued in one click when a phone is lost.
When staff reject a pay stub as out of date, the participant sees that reason on that item, sends a replacement, and the attempt history stays attached to it. Accepted items stay accepted.
Staff choose which receipts to share: a signed consent, a release of information, a sealed PDF with its document ID and hash. Nothing is shared by default, and every download asks for a one-time code, once per 15 minutes in one browser.
A panel on the enrollment record lists every request and receipt in the grant, with an Add and Remove control for each, an access log, and a plain card that says what the link can and cannot show.
Phone, mobile and preferred language in the first release, each as a checked, logged change. A change to the email the link is sent to is a later increment; until then, staff set it, so a stolen link cannot be re-pointed.
The screens
Design screens, rendered in the Salesforce Lightning style. Every organization, person, document and number is fictional sample data. Each screen carries a ribbon that says so.
01 · The participant's phone
In design. The participant opens one link and sees what needs attention first, then what is in review, then what is done. A request sent to the same person before the link existed is not on this page unless staff add it.
02 · Needs a replacement
In design. The staff rejection reason is shown on the item. The participant sends a replacement for that item only. The attempt history stays with the item, so a case manager and a participant see the same record.
03 · Shared receipts
In design. Receipts that staff chose to share appear in one list. Every download asks for a one-time code sent to the email on file; one code covers 15 minutes in one browser. The page says "Your download has started" and shows the document ID and signing date.
04 · The case manager's view
In design. The panel lists every request and receipt in the grant, with an Add and Remove control for each. An access log records each open, each code sent, each download and each change, with the staff name on every link action. A card on the right states what the link can and cannot show.
05 · Share a receipt
In design. Staff share one receipt to one participant with a label and an optional remove-after date. A code before download is always required; there is no switch to turn it off. The share is an explicit record, with a name and a time, and can be revoked at any time.
06 · Your details
In design. The participant can update phone, mobile and preferred language. Each change is a checked, logged request that staff can review. A change to the access email, with its recovery path, is planned for the increment after the first release.
The first version
Not in V1: message threads, appointments, general Contact or Case records, internal notes, unrelated files, clinical history, logins or accounts, SMS codes (email only at first), a self-service change of the access email (next increment), more than one enrollment per link.
Security posture
This page describes a participant request workflow. It makes no statement about Salesforce licences or about any Salesforce product. The design records a written-clearance step with Salesforce's ISV licensing team as a gate before any such statement is made.
Where it stands
The design is complete, down to the data model, the token lifecycle, the authorization model and the effort by phase. We build it with one case-managed program that pays for the first version, shapes the screens, and runs it with real participants first.
If your intake team spends its afternoons chasing replacement documents by text message, we want to hear how many hours a month that costs. A design partner keeps the price they signed at.
The Request Center builds on the Document Request add-on, which is also under development. See how AutoSurvey handles guest access today.