Forms in Portals
- 11 Mar 2025
- 7 minute read
- Print
- DarkLight
- PDF
Forms in Portals
- Updated 11 Mar 2025
- 7 minute read
- Print
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
You can add forms to a portal to let users make self-service updates to Slate data or reach out to staff. Form submissions are all tracked in Slate and are immediately associated with the relevant record.
Common examples of forms integrated in portals include:
Counselor contact forms
Change of major forms
Editing profile information
Ways to add a form to your portal
We cover three methods by which you can add forms to your portals:
⚙️ Form widget: Adding the dedicated form widget to a portal view lets you place the form in a pop-up
🔗 Link: Adding a link to the form to a static content block is best for long forms that need a whole page to view
📋 Embed code: Pasting the form’s embed code in a static content block requires the fewest steps to set up
Option 1: Adding the form widget to a portal view
Slate provides a dedicated form widget for portals with a number of configuration options.
When to use the form widget
Use the form widget if the scope of the form is the same as the scope of the portal.
For example, if an applicant logs in to their status portal and fills out a form regarding their application, that form submission should be associated with their application record, and you’d want to use the form widget to embed that form.
On the other hand, if the form to be filled out doesn’t share the portal’s scope, or shouldn’t belong to the logged-in portal user, use one of the other two methods we describe (using a link or pasting the embed code).
Adding the form widget
To embed a Slate form in a portal view:
Go to Database → Portals.
Select a portal, or create a new one.
Select the view in which you want the form to appear.
From the widget palette, select Form. Drop the widget it in the area in which you would like the form to be displayed for portal users.
Select the widget to edit it.
In the Edit Part pop-up, enter the following configurations:
Name: Provide a label for the part
Status: Active
Form: Select the form to display. The list includes all forms available in the forms tool, regardless of portal and form scope.
Submission Behavior (Optional): When selected, reloads the portal upon submission.
By default, submitting a form embedded via the widget will not reload the entire portal page.
If you are using filters to control what is visible on the portal and the form submission will change that data, reloading will show the updated view.
Popup (Optional): Formats the form to display as a pop-up, and upon submission, closes the pop-up.
Query String Parameters (Optional): Checking this box lets you pass the
personquery string parameter to the embedded form.
Other query string parameters can be passed by prefixing
form_to the parameter.If you’d like your form to access query string parameters without this prefix, use the form’s embed code as described in option three.
Select Save.
Example: Embedding a Contact Your Counselor form in the Applicant Status Portal
In the following example, a form is embedded as a pop-up in the applicant status portal that lets students send a message to their assigned counselor.
The pop-up contains the form itself, in which the student can enter their message.
Entering a message to an assigned counselor in the pop-up
Step 1: Creating a view
We create a new view to generate the pop-up that contains the embedded form.
We add a form widget to the view, name it Contact Form, select the form we want from the Form list, and select Form is inside a popup.
Step 2: Creating a method for the view
We create a new method and associate it with the Contact Form view.
We set the output type to Ajax Popup/No Branding, and we enter contact in the Action field. We refer to this value later, to call the method when the user clicks the link to the form.
Step 3: Adding a link to the pop-up to the main view
We create a static content block on the main view and enter the following HTML in the source editor:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<a data-href="?cmd=contact" href="#" onclick="return (FW.Lazy.Popup(this, {width: '750px'}));">Click here to contact {{staff_assigned_name}}!</a>
</body>
</html>Which produces this output:
In particular, we’re using the data-href="?cmd=..." parameter to call the portal method, in this case, referenced by its Action value, which we set to contact earlier.
🔔 Important! The
cmdindata-hrefmust match the action of the portal method.
Also in the static content, we include merge fields for staff-assigned (included in the Form Properties when we built the form) to display the name of the specific counselor assigned to the logged-in applicant.
The form can also be set up to send communications upon submission with the counselor as the recipient, and the message merged into the body of the mailing.
Option 2: Linking to a form in a portal
You can add a link to a form in the source code of a static content block.
<a href="/register/?id=form_guid_goes_here">Link to form</a>When the user selects the link, Slate opens a new form submission in the current browser window.
✨ Tip: Consider this option for lengthier forms that are easier to fill out if they occupy the entire browser window.
Redirect to the portal upon submission with the referrer parameter
In the link, you can pass the referrer parameter the key of your portal. Then, the portal user, rather than seeing the default confirmation page upon form submission, is instead redirected back to the portal.
The referrer parameter follows the this format:
&referrer=/portal/PORTAL_KEYSo the full link would appear like so:
<a href="/register/?id=FORM_GUID&referrer=/portal/PORTAL_KEY">Link to form</a>Pre-popoulate the form with query string parameters
The form URL can also use query string parameters to pass in the GUID of the record with whom the form response should be associated.
The specifications for this parameter are:
The parameter for passing in a record GUID is always
person, regardless of whether the form submission should ultimately be associated with a person, application, or dataset record.Liquid markup is used to merge in the GUID value. Here, the merge field is called
id, the name of the export in the portal query.The GUID must be included as an export in the relevant portal query. In this case, this is the applicant detail query associated with the detail method and view. The name of the export must match the name of the merge field exactly.
The form is application-scoped, and so the parameter value for person must be the application GUID to associate the form submission with the correct application record.
Here’s how that would look:
/register/?id=FORM_GUID&referrer=/portal/PORTAL_KEY&person={{id}}📝 Note that id here is not a placeholder.
📖 Further reading: Query string parameters
Example: Alumni interview report form
Here, an alumni interviewer can access and submit an interview report form for an applicant.
When the interviewer views their interviewee's details in the portal, they have the option to File Report. Clicking the link opens an interview report form in the same window.
With query string parameters, the form can be pre-populated with information already available in Slate for the applicant's record.
When submitted, the form response is automatically added to the applicant's record.
In the details pop-up view, the form URL contains two additional query string parameters: one for the referrer, and one for the application GUID.
Option 3: Using the form’s embed code
A Slate form's embed code can also be used to integrate the form into a portal.
📖 Further reading: Embedding forms
Example: Pledge fulfillment form in an Advancement giving portal
In this example, a donor logs into a giving portal and view their pledge history.
When they’re ready to fulfill a particular pledge, we want them to fill out a form with the payment details.
Step1: Copying the embed code
We first copy the form’s embed code.
We can add query string parameters later to pre-populate fields. For this, we can copy the Simple Embed code.
Or, if we want the form to intercept the query string parameters from the portal URL itself, we can select the Dynamic Embed tab and copy its code.
Step 2: Pasting the embed code
We then go to the portal view on which we want the form to appear.
Then, we paste the form’s embed code pasted into the source code of a static content block.
Step 3: Pre-populating form fields with query string parameters
When we add the form’s embed code into the portal view, we can pass in additional parameters to pre-populate certain form fields.
Liquid markup is used to merge the parameter values. The merge fields must exist as export parts in the relevant portal query.
Here’s an example embed code with additional query string parameters:
<div id="form_e552f605-1227-4310-bd71-f22a4f039a09">
Loading...
</div>
<script async="async" src="/register/?id=e552f605-1227-4310-bd71-f22a4f039a09&sys:gift:parent_identity={{identity}}&sys:gift:type={{type_guid}}&sys:gift:fund={{fund_guid}}&output=embed&div=form_e552f605-1227-4310-bd71-f22a4f039a09" type="text/javascript">/*<![CDATA[*//*]]>*/</script>
In this example, the additional query string parameters pass in values that populate hidden form fields.
Some fields are hidden since they don't need to be displayed or updated by the portal user at all. These hidden form fields allow the form data to map to the correct system fields.
For example, identity in this case refers to the pledge identity value, and is used to associate the gift to this particular pledge.
Was this article helpful?
