Building a Form in SAS Model Risk Management (Part 2)
In Part 1, we built a Priority Assessment form that calculates a score and displays a result in real time using the Embedded Builder. What that form still doesn’t do is persist anything. The Embedded Builder Page (EBP) lives entirely at runtime, which means without additional setup, every answer disappears as soon as the user navigates away.
In this post, we’ll focus on wiring the form into the Change Request object page, so its data is stored, reloaded, and made usable by the platform. That includes creating the supporting fields at the object layer, defining the formal relationship between Change Requests and Forms, and configuring the page so the form renders correctly and its results can drive real behavior.
Before we touch Cirrus Builder, we need to do some setup at the object layer. This work happens outside the UI and is handled through data loaders. The goal here is not to change how the form behaves, but to give it somewhere to store its data and a formal way to attach itself to a Change Request record.
Download the RegistrationFieldDefintions data loader using the REST API:
{HOST URL}/riskCirrusObjects/objectRegistrations/export
In the Excel sheet that get downloaded, open the RegistrationFieldDefinitions tab and filter by registrationFieldDefinitions.name = mrm_approvalChecklistData. This is the jsonObject data storage we will be replicating.
Add a jsonObject Field to the Change Request Object
The EBP component is not a field. It does not store data. So, when a user fills in the form and navigates away, those answers would be lost. The jsonObject field is the solution. It acts as a hidden save slot that captures a snapshot of the EBP data every time the record is saved.
In your Change Request object schema, add a new field with the following configuration:
- registration.sourceSystemCd: RCC (can be found on Registrations data loader)
- registration.id: ChangeRequest (can be found on Registrations data loader)
- registrationFieldDefinitions.name: x_cr_priorityFormData
- registrationFieldDefinitions.type: jsonObject
- registrationFieldDefinitions.description: Change request priority form data
Everything else can remain the same as the mrm_approvalChecklistData field.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Users do not interact with it directly. It exists purely to hold the EBP data between sessions.
With a place to store the Embedded Builder Page data, the next requirement is letting the Change Request object know which form it’s allowed to use. That association is not implicit. In SAS Model Risk Management, objects and forms are connected explicitly through link types.
The 100,000 character limit matters. EBP data is verbose. Make sure the limit is high enough to accommodate the full form payload.
Save your Excel sheet and load to SAS Model Risk Management > Data Load.
Create a Link Type
This link type defines a first‑class relationship between Change Requests and Forms. It’s what allows the relationship component and Embedded Builder Page to appear on the object page later.
Download the RegistrationFieldDefintions data loader using the REST API:
{HOST URL}/riskCirrusObjects/linkTypes/export
Open the LinkTypes tab and filter by linkType.id = mrm_approvalForm_changeRequest. This is the object to form linkage we will be replicating.
Note: Custom link types require a custom source system code.
Prerequisite:
- Download the Source Systems data loader ({HOST URL}/riskCirrusObjects/sourceSystems/export)
- Add a new Source System Code
| sourceSystem.sourceSystemCd | sourceSystem.name | sourceSystem.defaultFlg |
| XMRM | XMRM | FALSE |
- Save and load to SAS Model Risk Management > Data Load
Your Change Request page needs to know which Form to render. A link type is the formal relationship between your Change Request object and the Form object. Without it, there is no recognized connection between the two objects and no way to say "this Change Request uses this Form."
Create a new link type with the following configuration:
- Link Type ID: x_cr_priorityForm
- Object 1: Form
- linkType.side1Type: registration
- linkType.side1ObjectTypeName: Form
- Object 2: Change Request
- linkType.side2Type: registration
- linkType.side2ObjectTypeName: Change Request
On the LinkTypeOptions sheet, filter by mrm_approvalForm_changeRequest. We will be replicating this row as well.
| linkType.sourceSystemCd | linkType.id | linkTypeOptions.deletionRules.side1 | linkTypeOptions.deletionRules.side2 |
| XMRM | x_cr_priorityForm | BLOCK | DISCONNECT |
Save the link type Excel sheet. This is what enables the relationship component in the next step.
Load this data loader into SAS Model Risk Management > Data Load.
At this point, all required object-side plumbing is in place. We have a jsonObject field to persist Embedded Builder Page data, and we have a link type that formally connects Change Requests to Forms. As expected, nothing is visible in the UI yet. The final step is to surface these pieces on the Change Request page using Cirrus Builder.
Before we get into adding the components in Cirrus Builder, let's take a look at what we set up on the object side first. So far, two fields have been created using data loaders.
Two fields were added to the Change Request object:
- x_cr_priorityFormData, a jsonObject field that stores the EBP data between sessions
- x_cr_priorityForm, the field that will hold the score once the form sends it up.
Neither of these are visible in the UI. They work in the background to support everything the builder components and interactions depend on.
Cirrus Builder Set Up
With the backend configuration finished, we can now surface these pieces on the Change Request page. In Cirrus Builder, the link type becomes a relationship component, the jsonObject field becomes an Embedded Builder Page field, and the form itself becomes visible to users.
Open Cirrus Builder from the Applications menu > Manage Risk Solutions > SAS Model Risk Management.
From the Pages menu, copy the OOTB Change Requests page.
Open it.
Click the upper tabs to select them.
Click the Properties menu.
Add a new tab called Priority Score.
ID: priorityScoreTab
Click OK.
From the Properties menu, drag this new tab under the Details tab.
Rather than building this configuration from scratch, we’ll use the Approval Checklist implementation as a reference pattern. It already demonstrates the exact mechanics we need: form linkage, grouped layouts, and Embedded Builder Page fields.
From the Details tab, check out the Approval Checklists relationship component (mrm_linkedApprovalForm) and the groupable container (mrm_approval_checklist_container) containing three form layouts. We will be using this as a reference to add our new form to the Change Request object page.
Click the Priority Score tab. You may need to click the upper tabs first to see it appear in the Properties menu.
From Objects in the left menu, hover and click on the pencil icon for ChangeRequest.
Change the default page to the XMRMChangeRequest page you copied from earlier.
Expand the Relationships header.
Find the mrm_approvalForm_changeRequest link type we added in the LinkTypes data loader. Copy it.
Change the Relationship identifier to the linkType.id: x_cr_priorityForm.
Change Source System Code to the custom code from linkType.sourceSystemCd: XMRM.
Change the Source identifier to match your form, i.e x_mrm_linkedPriorityForm.
Source label (singular): Priority Score
Source label (plural): Priority Scores
Change the Target identifier to x_mrm_linkedChangeRequests.
Target label (singular): Change Request
Target label (plural): Change Requests
Relationship type: Lookup
Relationship cardinality: One to many
Related object type: Form
Click OK.
You can also find this linkage on the Form object.
From the Components menu, click the Fields subtab.
Drag the Priority Scores link component onto the screen or you can just click the component, and it’ll appear on the screen.
Click Save and add a relevant commit.
From Objects > Change Request, expand the Fields header.
Locate the Approval checklist data field (this is the one that holds the form data).
Make a copy of it as well.
In the Identifier field, change to x_cr_priorityFormData. This is from registrationFieldDefinitions.name: x_cr_priorityFormData in the RegistrationFieldDefintions data loader.
Change the Label to Priority score data.
Keep the Input type to Embedded Builder Page Field. This is how the field will show up on the page.
To clear the Column Header label, simply change the Input type to something like Dual Selector and then back to Embedded Builder Page Field.
Click OK twice.
Groupable Container Layouts
Now that we have the linkage component and the data field, we need to add the container layouts for default, empty, and assessment.
From the Components menu > General, find and click the Groupable Container component to add it to the screen. We will be putting an Embedded Builder Page Field inside of that container.
Note: Make sure you have selected the tabs container first.
Change the ID to x_priorityFormContainer.
Expand the size of the container.
Click into it to select it.
Notice in the right Properties menu, there are options to Add layouts.
Click Add layout.
Change the ID to zero_state_layout. This layout will hold the empty state when no form has been selected.
Repeat for the assessment layout (ID: assessment_layout). This is what will display your form.
Click the assessment_layout layout to select it.
From the Components menu.
Drag the Embedded Builder Page component onto the screen—or you can just click the component, and it’ll appear on the screen.
Make sure the assessment_layout container is selected first.
Change the ID to x_priorityQuestions.
Change the Label to Change Request Priority Questions.
Zero State Container Layout
In the zero_state_layout container, add an image and rich text components.
Image:
ID: x_mrm_zero_state_image
Image: ZeroStateAdd
Rich Text:
ID: x_mrm_priority_zero_state_text
Label: Select a priority form to begin assessing this change request.
Adding the Color Dropdown Field
Since we will be displaying a field from the form to the Change Request page, we will need to add another field.
We will be recreating the Color Dropdown from Part 1 that displays the color value.
Add a new field in the Registrations data loader called Priority Score.
ID: x_cr_dd_priorityScore
Description: Change request priority score
registrationFieldDefinitions.type: optionCd
registrationFieldDefinitions.maxLength: Empty
registrationFieldDefinitions.listName: x_cr_list_priorityScore
Load this Excel sheet into SAS Model Risk Management > Data Load.
Add the Named List for the Dropdown Values
The listName we just referenced (x_cr_list_priorityScore) points to a named list that does not exist yet. This is where the dropdown's Low, Medium, High, and Critical values actually come from. Without it, the field has nowhere to pull its options from.
Download the Named Lists data loader using the REST API:
{HOST URL}/riskCirrusObjects/namedLists/export
On the NamedLists tab, add a new row to declare the list itself:
| namedList.sourceSystemCd | namedList.id | namedList.listName | namedList.sortMode |
| XMRM | x_priorityScore_list | x_cr_list_priorityScore | options |
Note that namedList.listName is what the registration field's listName points to, while namedList.id is the unique identifier for the list record itself. sortMode: options means the dropdown will display values in the order the options are defined (rather than alphabetically).
On the NamedListOptions tab, add one row per dropdown value. The namedList.optionCd is the stored code; we will set the user-facing label on the translations tab.
| namedList.listName | namedList.optionCd | namedList.customJson |
| x_cr_list_priorityScore | X_LOW | (empty) |
| x_cr_list_priorityScore | X_MEDIUM | (empty) |
| x_cr_list_priorityScore | X_HIGH | (empty) |
| x_cr_list_priorityScore | X_CRITICAL | (empty) |
On the NamedListTranslations tab, add one row per option to define the display label users actually see in the dropdown:
| namedList.listName | namedList.optionCd | namedListTranslations.languageCd | namedListTranslations.label |
| x_cr_list_priorityScore | X_LOW | en | Low |
| x_cr_list_priorityScore | X_MEDIUM | en | Medium |
| x_cr_list_priorityScore | X_HIGH | en | High |
| x_cr_list_priorityScore | X_CRITICAL | en | Critical |
Save the Named Lists Excel sheet and load it into SAS Model Risk Management > Data Load before loading the Registrations data loader, so the listName reference resolves.
Load the Named List Excel sheet into SAS Model Risk Management > Data Load.
Adding the Dropdown Field to Cirrus Builder
Open Cirrus Builder > Objects > Change Request > Fields > New field.
Identifier: x_cr_dd_priorityScore (same as registrationFieldDefinitions.name)
Label: Priority Score
Input type: Color Dropdown
Column heard label: Priority Score
Searchable and sortable in tables: checked
Click Add dropdown option.
Add these values. These are the same values as the Form uses.
| Label | Value | Color Hex Code |
| Low | X_LOW | #7AF787 |
| Medium | X_MEDIUM | #F7D27A |
| High | X_HIGH | #FF9999 |
| Critical | X_CRITICAL | #EB502A |
Click OK twice.
From Components > Fields, drag the Priority Score field under the Priority Score groupable container.
Click the dropdown.
In the Properties menu, check the box next to ‘Display this dropdown as read-only text.’
Save your changes and add a relevant commit message.
Structurally, everything is now in place: fields, relationships, containers, and layouts. What’s still missing is the behavior that loads the form, captures its output, and writes results back to the Change Request record.
If you previewed your changes and navigated to the Priority Score tab, you would only see a read-only Priority score. You would not see the embedded builder or linkage component. We need to set up interactions first.
By the end of this part, you’ve completed the essential setup that make the Embedded Builder Page usable in SAS Model Risk Management. Instead of a temporary, runtime-only experience, your form now has a place to store data, a defined relationship to the Change Request object, and the structure needed to appear on the page. You will not see dynamic behavior just yet, but this foundation is what makes everything else possible. In Part 3, we will bring it all together by configuring the interactions that load the form, capture user input, and write results such as the priority score back to the Change Request so they can be viewed in a dashboard report.
To download the asset files, click here.
