EPBCS (Enterprise Planning and Budgeting Cloud Service) was Oracle's expanded planning offering built on top of PBCS (Planning and Budgeting Cloud Service). Oracle has since unified both into a single Oracle Fusion Cloud EPM Planning business process, where what used to be sold as EPBCS now shows up as the Modules application type. The name has changed, but the underlying decisions you have to make before you create the application haven't, and they still matter just as much, because several of them are permanent.
That's the core reason this article exists: a few configuration choices you make during application creation cannot be changed afterward. Get them wrong, and the only real fix is deleting the application and starting over: with all the reconfiguration, re-imported metadata and data, and rebuilt forms and business rules that implies. It's worth slowing down here.
Following along with screenshots? Rather than reproduce Oracle's copyrighted UI images, this walkthrough links to Oracle's official documentation for the current application-creation and module-enablement screens. Oracle's Creating an Application and About Planning Modules and Strategic Modeling references walk through the screens described below.
Application Type Is a One-Time Decision
The first choice you make is the application type, and it cannot be changed once the application is created. The main options are:
- Custom: for complex, highly customized planning and budgeting requirements, supporting business rules, allocations, and either single or simplified multicurrency.
- Free-Form: for building an application around your own dimension structure rather than Oracle's predefined ones, without the standard Currency, Entity, Scenario, and Version dimensions.
- Modules: the application type formerly associated with EPBCS, which sets up predefined cubes for Financials, Workforce, Capital, Projects, and Strategic Modeling, built on Oracle's best-practice content.
Depending on your subscription, you may also see more specialized application types at creation time (Sales Planning, Strategic Workforce Planning, and Predictive Cash Forecasting among them), each purpose-built for a specific planning process rather than the general-purpose Modules structure. Choose based on what the business actually needs to plan for, not which type looks the most flexible on paper: flexibility you don't use is just complexity you have to maintain.
Enabling a Module Is a One-Way Door
Within a Modules application, there are five modeling features to consider enabling:
- Strategic Modeling
- Financials
- Workforce
- Capital
- Projects
Here's the consideration that matters most: once you enable a feature, you can't later disable it. Oracle's own documentation states this plainly: "After you enable a feature, you can't later disable it." Each module you turn on generates its own dimensions, forms, calculation rules, member formulas, and dashboards, and all of that predefined content stays in the application permanently, whether or not the business ends up using it.
You don't have to enable everything up front: Oracle explicitly supports enabling only the features you need at first and incrementally enabling additional ones later as requirements grow. That incremental path only runs in one direction, though, so the real planning question isn't "what do we need today," it's "is there any realistic chance we'll need this module in the next year or two, and if we enable it now, are we comfortable living with it even if we end up not using it."
One module is the exception to the configuration-effort story: Strategic Modeling requires no additional configuration tasks after it's enabled: Oracle's documentation confirms there are no required setup steps beyond enabling the feature and logging back in, after which the provided templates are populated automatically. Financials, Workforce, Capital, and Projects all require some amount of follow-on configuration (dimension mapping, feature-specific settings) to get from "enabled" to "usable."
Practical Considerations Before You Click Create
- Confirm the application type with the business requirement, not the implementation timeline. Reversing a Free-Form-vs-Modules decision after go-live means rebuilding the application from scratch.
- Treat every module as a permanent commitment. If Workforce or Projects might be in scope within the planning horizon your organization typically works with, it's worth the conversation now rather than after Financials has already been in production for six months.
- Map out required dimensions before the first enablement, not after. When you enable a module like Projects for the first time, you must include every dimension you intend to use in that first pass; you can enable additional features later, but you can't go back and add dimensions you skipped the first time around.
- Budget time for module-specific configuration, since only Strategic Modeling is truly plug-and-play; the others need real setup work before business users see value.
Key Takeaways
The considerations above exist for one reason: certain decisions in Oracle Fusion Cloud EPM Planning (application type and module enablement chief among them) are permanent. Making the wrong call doesn't just create a support ticket; it typically means recreating the application entirely, along with every dependent piece of configuration, metadata, and data that's already been built.