Use this community-contributed example to collect a short audio recording of a person's name pronunciation and make the recording available in staff-facing record views. The example stores the recording as Base64 text in a person-scoped field, then reconstructs that text as playable audio in a dashboard or portal component.
This can be helpful for advising appointments, phone outreach, and other contexts where staff should hear how a person says their name.
Try a Slate example 💼
Copy this Suitcase ID and paste it in Database → Suitcase Import to import a pre-made example:
f1778728-2407-4c6a-833e-90f4aa82d77c:slate-success-showcase⭐ Get Inspired
This article was adapted from a post by Technolutions staff in the Slate Community Forums' Get Inspired space. Have a great idea for a Get Inspired post? Let us know!
How the example works
The example has four main parts:
Person-scoped field: Stores the Base64 audio text on the person record. The source example uses
audio-name.Person-scoped form: Provides the field that receives the recording value.
Person-scoped recording portal: Confirms the person, captures audio in the browser, converts the audio to Base64 text, and submits the value to the form field.
Person dashboard playback component: Reads the stored Base64 text and converts it into playable audio for staff.
📝 Note
Keep recordings short. The source example limits recordings to approximately four seconds because Base64 encoding increases the stored text size by about 33%. Use this pattern for short pronunciation clips, not longer audio submissions.
Before you begin
Before you build or adapt this example, decide where each part of the experience belongs in your database.
Identify where students or other people should access the recording portal.
Decide which staff-facing views should include playback, such as person record dashboards, advisor portals, one-stop views, or student success portals.
Review who should have access to the recording and playback views.
Test the example in a test environment before adding it to a production workflow.
Creating the storage field
The recording must be stored on the person record so it can be reused across staff-facing contexts.
Go to Database → Fields.
Create a person-scoped field for the recording value.
Use a computer-friendly ID for the field. The source example uses
audio-name.Configure the field so it can store the Base64 text output created by the recording portal.
Save the field.
Building the recording form
The recording form connects the portal recording experience to the person-scoped field.
Go to Forms.
Create or open a person-scoped form.
Add a field that maps to the person-scoped pronunciation field.
Add any identity-confirmation text or merge fields that help the person confirm that they are recording the pronunciation for the correct record.
Save the form.
For more information about adding person data to form content, see Merge Fields on Forms.
Configuring the recording portal
The recording portal provides the public-facing or authenticated page where the person records and submits their name pronunciation.
Create or open a person-scoped portal.
Add the recording form to the portal.
Add the portal code that records audio in the browser.
Configure the code to convert the audio recording to Base64 text.
Write the Base64 value to the form field that maps to the person-scoped pronunciation field.
Save the portal.
💡 Tip
Browsers usually ask for microphone permission before recording audio. Include clear portal text so people understand why microphone access is requested and what will happen after they submit the recording.
Adding staff playback
After a recording is stored on the person record, add the playback component to the staff-facing place where staff will use it.
Open the person dashboard, advisor portal, or other staff-facing view where playback should appear.
Make the person-scoped pronunciation field available to the component.
Add the playback code that reads the Base64 value and reconstructs it as playable audio.
Show the playback control only when a recording value exists.
Save the dashboard or portal view.
Testing the workflow
Test the full recording and playback path before making the workflow available to a wider audience.
Open the recording portal as a test person.
Allow microphone access when the browser prompts for permission.
Record a short name pronunciation and submit the form.
Confirm that the person-scoped field stores the submitted value.
Open the staff-facing dashboard or portal view.
Play the recording and confirm that the pronunciation is clear.
Test a person record without a recording to confirm that the empty state is clear.
After testing, share the recording portal with the intended audience and add the playback component to the staff views where name pronunciation will be most useful.