Capture New Data From Your Users with Forms
Creating new list items and capturing data against them forms a critical part of many planning processes, especially those that seek to democratize planning by engaging end users in a wider range of planning activities. Forms are a new input mechanism added to the Anaplan UX that allow you to create simple, intuitive input forms that feel familiar to end users and submit data directly into your models.
Let's look at a simple example where forms can support a planning process:
Scenario: You've been tasked with creating a set of pages in Anaplan's UX to support a simple headcount planning process where department heads need to log their recruitment requirements for the next financial year. Your contributors (department heads) need to create new required team members within the correct teams, add a job role level, a ramp profile, and a start date. This data can then be used to get a complete picture of recruitment requirements and cost across the business for the next year.
While in reality, the model will be more complex, we'll focus on a couple of lists and a single module for this example.
Our Model
For this example, we'll use a simple composite list to represent our team and requirements structure. We'll define a teams list to outline the structure of the organization and a requirements list to hold all of our headcount requirements.
Our teams list is a simple list set with a top-level item of All Teams.
We've set our requirements list up as a numbered list using teams as its parent hierarchy. To show the full range of forms functionality we've also added two properties to our requirements list to track the project we anticipate the new hire moving onto—and these are both set to text formatted.
The module we'll use to track our requirements across the organization will be relatively simple and will only be dimensioned with the requirements list and a series of line items.
We've also added a third, simple list that will help us to track headcount requirements across different years.
Creating Our Form
We'll start by building a simple worksheet in our new Headcount Planning app that will house our requirements module. This will be a simple, grid-focussed view that will let us track all of the incoming recruitment requirements in a single place.
We've made sure our view is pivoted with planning years on pages and our requirements list and line items visible within the grid.
We'll use this worksheet as our main headcount planning space, so we should now add a form to the page to allow our contributors to submit their requirements. We'll click into edit mode for the page and open the configure worksheet actions panel where we can decide what actions our end users can perform when working with this worksheet.
Opening up the forms section in the right-hand panel gives us the opportunity to reuse an existing form or to create a new one. As this page is a new requirement for our process, we'll click to add a new form.
We can give our form a name so we can track it as part of our app, and we'll choose the list we want the form to insert data into.
Adding List Properties
Before proceeding with list properties you should carefully consider the overall design of your model. You can read more about this in David Smith's best practice article on module design. In the example we're looking at we've decided to track a couple of bits of data as list properties, so we'll add those to our form.
By toggling the switches for our project name and project code list properties we can add those fields to our form for our end users to complete. Note the form preview update in real-time to show us what our form will look like.
List Item Parent Selection
In this example process, we want each department head to be able to choose the team their required recruit should be placed. We'll use the 'allow user to choose parent' toggle to add a parent selector into the form for them to fill out.
If we wanted to restrict where contributors can add data, we could leave this toggle in its off position and instead define the parent ourselves. By doing this, any new list items created by this form will be automatically assigned to that parent where a downstream process could be used to assign them to their correct location.
Populating Module Line Items
The majority of data we need to capture from our contributors in this form are actually mapped to line items in our module. Luckily, we can use forms to both insert a new list item and then proceed to fill in line item values in a chosen module.
First, we need to select the module we want to insert data into.
The 'choose module' dropdown lets us browse all of the modules in our model where at least one line item is dimensioned against the list we've chosen Once a module is selected we'll be given a list of available line items we can add to our form. Note that read-only line items, typically those driven by formulae, are excluded from this list ensuring we only ask contributors for inputs they can actually provide.
Each time we add a line item to our form we can see the preview update until we're happy that the form is capturing everything we need. As we're using a worksheet to launch our form, users can still edit values directly into the grid once their requirement has been added, but the form helps to minimize the need for manual grid editing as part of this process.
Validating Data Input
Our form is now structurally complete and ready to publish, but we've had some last-minute requirements from our Human Resources (HR) department:
Additional requirements: HR would like to insist that all project codes used for headcount requirements consist of uppercase letters and numbers only. In addition, please refrain from using numbers and special characters when providing job role information. Remember that project names and codes, as well as job roles, must be completed when requesting a new hire.
Luckily, we can use the inbuilt validation features of forms to help our users get this right first time. Let's start by selecting our project code field in the form preview and clicking its cog/settings icon.
Using the validation rules side panel we can configure this field to only allow the required characters—uppercase letters and numbers.
By setting these validation rules, if a user tries to add a new headcount requirement and their values for these fields do not match the required rules, then the user will be informed and told how to resolve the issues.
HR has also requested that a number of fields in the form are mandatory. We can use the validation rules to insist that users complete these fields before the form can be submitted.
For each of the required fields, we click the cog/settings icon and define the field as required. You'll see the form preview updated to show a red * next to all required fields so the user can clearly see what must be completed when using the form.
Note that validation rules can only be applied to text formatted properties and line items.
Using Context Filters
As our module, or at least one line item in our module, is dimensioned against something on pages you'll see that our form has detected this and given us a context filter within our form.
As a builder, we can decide what our users can do with this dimension (in our example, the year against which requirements are added) we can click the cog/settings icon for the context filter and decide whether the filter should be hidden in our form, visible but not editable, or fully editable by end users in the same way as with our existing board cards.
We can also decide whether or not the context filter should automatically set itself to match the context on the page. This is the default as it will ensure new line item values are submitted into the slice of data that's currently in view. If you want to default this to something else then you can select a default when designing your form and adjust the copy from page toggle.
Adding the Form to Our Planning Process
With the example workflow we're designing for, we're happy that users can land on the worksheet and use the form to add their data. Enabling this is easy as we can just switch the form on using the toggle in the right-hand panel after we've clicked configure worksheet actions.
Let's take a look at this from the perspective of an end-user...
As our contributors land on the worksheet, they can click the + button to launch the form. The form we designed then guides them through the process of logging their recruitment requirements.
Users are provided with relevant validation messages as they fill out their form, and when everything's ready, submitting the form adds list item and line item values directly into our module.
Forms on Boards
Our worksheet is now live and shared with our contributors (remember URLs in the New UX are all unique so you can copy and share links) and everyone's adding their requirements giving recruitment and HR great visibility for the coming year.
Things are going so well—in fact, you've just received this note from your director of operations:
Great news! The form you've built in Anaplan is working brilliantly, and we've got more visibility of upcoming hire requirements than we've ever had. Nice work. One last thing though, could we enable the creation of new requirements directly from our HR Ops dashboard? Let me know if this is doable.
The good news is that once a form has been built it can quickly be added to any of the boards in the same app.
We can quickly jump into edit mode for the board, and we'll add an action card that will let users launch our form. Editing the action card lets us choose which forms (or actions) we want to include as buttons. Here we've toggled our new form to on.
Our new action button has now unlocked our form for use on the HR ops board, and a whole new audience of end users can launch the form to add new hiring requirements.
Further Reading