Forms in Portals
- 12 Sep 2024
- 6 minute read
- Print
- DarkLight
- PDF
Forms in Portals
- Updated 12 Sep 2024
- 6 minute read
- Print
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
Forms can be used in portals to update Slate data. A form can be created with the forms tool and then be integrated with a portal in a few different ways.
Slate forms are built with the form builder's drag-and-drop interface, which means that it would not be necessary to add custom HTML or scripts within the portal to replicate form functionality. Form submissions are all tracked in Slate, and are immediately associated with the relevant record as well.
Some common examples of forms that are integrated in portals are Contact a Counselor, Change Your Major, or Edit Your Profile.
Embed a Form Using the Form Widget
To embed a Slate form using the form widget in portal views, first navigate to the view in which the form should display. In the view, select form from the widget palette, and drag and drop to the area in which you would like the form to be displayed for portal users.
In the Edit Part window, enter the following configurations:
Name - Provide a label for the part.
Status - Set to Active.
Form - Select the form to display. The list will include all forms available in the forms tool, regardless of the portal's or forms' scope.
The following settings are optional:
Submission Behavior - By default, submitting a form embedded via the widget will not reload the entire portal page. To reload the portal upon submission, check this box. 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 - Checking this box formats the height of the form to display in a pop-up, and upon submission, closes the pop-up.
Query String Parameters - Checking this box allows the “person” query string parameter to be passed 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 the section below.
Best Practice
Using the form widget is recommended if the scope of the form is the same as the scope of the portal (i.e. the security setting that indicates the type of record that will be authenticated by the portal). For example, an applicant logs in to their status portal and fills out a form that should also be associated with their application record.
If the form to be filled out is not the same scope or should not belong to the logged-in portal user, the other two methods (providing a hyperlink or using the form embed code) described later in this article should be used.
Example: Contact Your Counselor Form
In the following example, a form is embedded into an applicant status portal that allows students to send a message to their assigned counselor.
The pop-up contains the form itself, in which the student can enter their message.
Since the form is displayed within a pop-up, a separate view is created in the portal, and the form is added via the widget. A new method is created as well and will be associated with this specific view.
Source code:
<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>Important!
The cmd in data-href must match the action of the portal method.
This form also uses merge fields 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.
Hyperlink to a Form
A link can also be added (via a static content block) which, upon clicking, can open a new form submission in the same window and then redirect back to the portal after submitting or open in a new tab.
The URL of the form can use query string parameters to pass in the GUID of the record to which the form response should be associated.
More information on query string parameters can be found here.
Tip
You might consider this option if the form is lengthier and would be easier to fill out if it occupies the entire browser window.
Example: Alumni Interview Report Form
This example illustrates how an alumni interviewer can access and submit an interview report form for an applicant.
When the interviewer views the interviewee's details in the portal, a link is available that opens up an interview report form in the same window.
The form can be prepopulated 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.
The referrer parameter value is /portal/[portal key]. The referrer parameter allows the portal user to be redirected back to the portal after submitting the form, instead of being shown the default confirmation page.
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), and Liquid markup is used to merge in the GUID value (here, the merge field is called "id", as that is the name of the export in the portal query).
Example URL:
/register/?id=GUID OF FORM&referrer=/portal/PORTAL KEY&person={{id}}Important!
The GUID must be included as an export in the relevant portal query (in this case, 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.
Using the Form Embed Code
A Slate form's embed code can also be used to integrate the form into a portal.
Example: Advancement Giving Portal - Pledge Fulfillment Form
In this example, a donor can log in to a giving portal and view their pledge history.
When they are ready to fulfill a particular pledge, a form is available for filling out the payment details.
The form embed code can be copied and then pasted into a portal view (via a static content block's Source).
Tip
Although you can hard-code query string parameters as described below, you may want your form to intercept the query string parameters from the portal URL itself. To do this, make sure to use the Dynamic Embed code.
When adding a form embed code into the portal view, the code can be edited to pass in additional parameters that can 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.
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 particular 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?
