Form Design

Form Design Overview

You'll build a number of forms to support data entry and summary-level reports. The form content is similar to the templates you use to collect and calculate data. The layout may differ from what you are accustomed to in spreadsheets.

To enhance usability, group forms within major categories such as Revenue, Compensation Expense, Other Expenses, and so on. You can create some forms to support data entry, and others for summary and review. You can also include charts to help users analyze results.

Form performance is based on several factors, including network and environmental factors, structure, and layout.

Design Considerations

Design forms to enable users to enter information such as revenue, expenses, and assumptions.

Best practices:

Group accounts logically, but don't include too many accounts on a single form.
Limit the number of entry forms to an amount comfortable for end users. A delicate balance needs to be achieved between the number of accounts on a single form and the number of forms required to support your process.
Use detail forms to enable users to enter all related information. All accounts that require input should be found on a form. The accounts can be broken down into several different forms.
While building forms, ensure that you select all appropriate options to enhance the design of your form. For example, use settings to control precision, display, and menus, and to associate the proper rules with your form.
Use Substitution Variables to reference dimensions such as Years.
Suppress invalid Scenario/Time Period option, set Periods in row or column on the form to the Start and End Period set for the Scenario. Leveraging this functionality can be used instead of substitution variables for Years.
Consider setting valid intersections to set relationships between different dimensions. Suppressing invalid combinations can be set in row or column to make only valid intersections available to end users. By default, only valid intersections will be available to the end users when the dimensions are set in the Page selection.
Use relationships to incorporate members onto the forms instead of picking members individually.
Consider using User Variables for dimensions such as Entity and Scenario to help reduce the dimension selection for end users.
If your application supports multiple currencies, consider setting a User variable so users can define their base currency.
Organize forms into folders.
Use substitution variables to reduce the maintenance on forms.
Put dense dimensions such as Account and Period on the row and column of a form. Put sparse dimensions such as Entity on the Page axis.
Dimensions such as Scenario or Version and Year can reside on the POV, column, or row. It's important to properly gauge how columns or rows will be returned when a user opens the form.

Associate Rules with Forms

Associating rules with forms enables users with appropriate access to launch associated business rules from the form to calculate and derive values.

You can associate multiple business rules with a form by cube. Business rules associated with a form can be set to launch automatically when the form is opened or saved. You can select Use Members on Form to populate runtime prompts from the current form instead of prompting users for input when rules are launched.

Best practices:

For rules that take longer to run, set them to launch from an Action menu or simply through association with the form.
If a business rule has runtime prompts, limit the number of prompts to keep the user’s job simple.

Add Menus to Forms

You can associate menus with forms. Action menus allow users to click rows or columns in forms and select menu items. For example, they can launch a business rule, with or without runtime prompts, or move to another form.

Menus are context-sensitive. The menus that display depend on the form settings and where users right-click in the form.

Best practices:

When designing forms, use Other Options to select menus available for Form menu item types.
As you update applications, update the appropriate menus. For example, if you delete a business rule referenced by a menu, remove it from the menu.

Build Data Validation Forms

Data validation can serve as a visual clue to users that business policies have been met. You can add conditional color coding to forms, and validation messages can be generated if entered data violates validation rules or if a condition is met.

Defining data validation rules involves these main tasks:

Identify the data cells or location that you want to display with validation messages or in different colors when conditions are met. Be mindful of accessibility concerns if color is the only differentiator.
Identify the cell, column, or row that needs to participate during rule evaluation, and define the rule accordingly.
Create the data validation rule at the location identified.

Organize Forms into Folders

Use folders as a way to organize the forms in your application. Forms can be grouped in folders by process or user type, or simply to help users readily find forms. You can move forms into folders, and you can create a folder hierarchy. Creating folders also simplifies assigning access because all forms in the folder will inherit the access permissions assigned.

Build Summary Level Forms

Summary level forms typically bring together all of the pieces of a user's plan or forecast. They enable users to review and analyze their results.

Using dashboards can also be an effective way to help users analyze their results.

Forms and Cubes

When you create a form, you associate it with a cube, which determines the form's valid members. For example, if you assign a form to the Revenue cube, you can add only accounts that are valid for the Revenue cube. Entered data is saved to the selected cube's database.

Note:

You can't change a form’s cube after assigning it.
You can edit form accounts only if their source cube matches the form's cube.
If you add an account to a form associated with a cube other than the account’s source cube, the account is read-only on that form.

Forms and Permissions

Assign permissions to a form to determine which users can modify its design (for example, layout and instructions) and input data. Users can input data on forms only if they have permission to one secured dimension’s member. For example, if users have read-only permission to the Europe entity, the rows and columns that include the Europe entity are read-only. Users can change data only for members to which they have write permission.

Forms and Versions

For bottom-up versions, rows and columns with level 0 members allow data entry. Rows or columns set to a parent member are read-only. The point of view must also be set to the level 0 member to allow data entry on a bottom-up version. Target versions allow data entry in parent and children members set to Store.

Filtering Form Members by Attributes

You can select members by using attributes. For example, on the Entity dimension you can select members by a specific Region such as South. The resulting grid will only contain members that have the South attribute (for example, TX, NM, and so on). Values can be entered and saved into rows and columns filtered by attributes.

Forms and Shared Members

Because you can't select shared members individually, select them using a relationship function. For example, select an alternate functional rollup to include all members under that rollup. Users can enter values in rows or columns that display shared members, and data is saved to the base members in the database.

Forms and Calculations

To optimize calculations, select row members using relationships (such as Descendants or Children) instead of selecting individual children. For example, calculating individual parent-level totals could take several passes, so use a relationship instead.