Considerations When Creating Activities

Volume Considerations

Although there are no hard limits on the number of activities that a single model supports, the design and use cases have assumed an approximate maximum of 12 activities in a single model. If during the course of designing a model the candidates for activities exceed twelve, then consider making these items members of a dimension instead of an activity. Individual departments, products, projects and customers, for instance, would be good candidates for dimensions instead of activities.

Certain dimension-type data that should not be set up as an activity include: scenarios, versions, time periods, and currency. All of these items have special behaviors and are supported as distinct features in Planning and Budgeting.

See Understanding Planning and Budgeting Parameters.

See Understanding Multiple Currencies.

See Activity Versions.

Approval and Security Considerations

Each activity can have its own user security. A common requirement is to secure certain data for a common dimension (such as a department) by function or area. For instance, a person preparing or reviewing a department spending budget should be restricted to only viewing salary and compensation data at a rolled up level. Different users may access the position budgeting activity separately from the line item activity, thereby preserving employee compensation data anonymity. Likewise, certain users may require access to the revenue plan, some may require access to the spending plan, and others may require access to both. If most users have access to one or only a few activities, then they don't have to span multiple activities. The more intuitive the user-experience, the easier the training, and fewer user errors may occur.

The My Planning Workspace, data analysis and data entry views support a single activity at a time. This is the primary interface for all users. Consider segregating the model into separate activities to help filter what the users see and work with. Putting all data into a single activity may confuse users with irrelevant dimensions on certain rows, exposing more data to users than they need to see. My Planning Workspace was designed with multiple activities in mind, to quickly filter through a wide range of disparate data in a model. However, when analysis or data entry requires disparate data to be in a single view, then consider implementing fewer activities to get the most information on a page or at least consider the Includes Data From activity relationship option to copy certain key data from one activity to another.

See Establishing Activities and Activity Groups.

If different areas of the enterprise have different approval and security requirements, then consider grouping these areas into separate activities. For instance, the users' data and budgeting approval process can be quite distinct by function or geographic area. Revenue, project, and overhead spending often exhibit different characteristics for budgeting and planning purposes. Revenue may be planned by product, customer, or market. Revenue planners may require security based on their products. Revenue plans may get approved by product families. Projects will have their own approval paths and project groupings, as well as security requirements. Department overhead spending may be yet another area that is planned differently, by another set of users.

Another alternative to defining security is to assign secondary security for a given line item activity. This secondary security option, when enabled at the line item activity level, is equivalent to row level security for a specific dimension. For example, in addition to assigning department as the planning center and associating the security group to it, a secondary security could be applied at the account level. In this case, you can allow users access to certain accounts, or alternatively allow them to see the row, but not to update it. You should review this feature in conjunction with your security requirements around data entry and access within your activity, since users that do not have access to all the data in a given planning center will not be able to perform certain actions.

See Setting Up Planning and Budgeting Security Groups and Secondary Security Groups.

Dimension Considerations

Each activity supports optional dimensions. Dimensions enable analysis, formula building (methods), and reporting for various areas of an enterprise. Rather than putting all dimensions in a single activity, each activity can support a tailored set of dimensions and dimension members. A revenue activity may require product, customer, or sales region dimensionality to forecast future growth. An overhead expense activity may require cost center and geographic dimensionality. If the dimensions required for modeling, analysis, and reporting vary considerably from one area to another, then consider different activities by key areas.

Modeling Dependencies and Timing Considerations

You should also take into consideration modeling dependencies. The flexible formula (FLEX) method supports designing formulas that span multiple line item activities. However, there are certain order dependencies that disallow formula references between activities (to avoid systematic circular reference errors). In the case of multiple activities such as revenue and expense, an expense activity may reference and use data from the revenue activity, but the system will preclude the opposite condition where revenue references expense activity data. Formulas contained within a single activity have the fewest restrictions. The system also supports copying data from one activity to another (also known as the Includes Data From activity relationship).

See Activity Page.

Worldwide deployment may be another criterion to consider when choosing multiple activities. The budgeting process and timing may vary based on data composition or enterprise culture. Financial and source systems and release versions as well as software suppliers may vary by region, driving different data staging and export process requirements. Each activity can be staged and exported separately.

Each activity supports a start and end date. Depending on the budgeting process and data dependencies, certain areas of the enterprise may need to be complete before other areas can begin. There may be functionality dependencies such as completing the revenue plan before beginning the expense plan and finalizing the balance sheet and cash flow plan. Similarly, a worldwide enterprise may want certain key geographic regions to complete their budgets before other regions begin. Having separate activities makes the budgeting process clearer and easier to administer.