1.1 Workday Products, Functional Areas & Product Touchpoints

Why this matters on the exam

The Platform Administrator exam opens with The Workday Platform module, and its first two objectives are identify the Workday products and functional areas and recognize the Workday product touchpoints. These are not throwaway warm-up topics. Almost every later objective - security, business processes, reporting, integrations - assumes you can name the functional area that owns a domain, and the exam repeatedly asks scenario questions of the form "you changed X in one area; what else is affected?" That question is only answerable if you understand the touchpoint model.

One system, many products

Workday is a single unified application, not a suite of separately purchased systems bolted together. Every customer runs on the same codebase, and every product in a tenant shares one object model, one security configuration, and one business process framework.

Customers license products (sometimes called applications):

Functional areas: the unit that actually matters

Beneath products, Workday delivers the application in functional areas. Examples include Staffing, Core Compensation, Organizations, Personal Data, Benefits, Financial Accounting, and Procurement. A functional area is the container that holds two things:

• Domains - collections of securable items (tasks, delivered reports, report fields, data sources, data source filters, web service operations) that share the same security.
• Business process types - the event and transaction types (Hire, Change Job, Expense Report Event) whose workflows you configure.

The critical rule, stated plainly in Workday's own courseware: functional areas, domains, and business process types are Workday-owned and delivered. Customers cannot add, remove, or rearrange them. What you can configure is who has access - by creating security groups and adding them to security policies - and how a business process definition routes.

Enabling a functional area

Not every functional area is enabled in every tenant. Phased deployments are common: you may go live on Staffing and Core Compensation first and enable Advanced Compensation a year later.

• Use the Maintain Functional Areas task to enable or disable a functional area. The task lists every delivered functional area with its domains and business process types, and you select the checkbox in the Enabled column.
• Use the Functional Areas report to view the same structure without changing it - useful when you simply need to know which functional area owns a domain.

Trap: enabling a functional area does not grant anybody access. You still have to add security groups to the relevant domain security policies and then run Activate Pending Security Policy Changes. Two separate steps, two separate failure modes.

The cross-application framework

Because every product in the tenant shares one security configuration, a security change scoped mentally to "just HR" can break Finance. Workday's own example is worth memorizing: if you remove the Report Writer security group from the Custom Report Creation domain security policy, members of that group can no longer create custom reports anywhere - regardless of the functional area they normally build reports for.

This is the essence of the cross-application framework, and it is why the exam favors answers that include "test the change in Sandbox first" and "check which other functional areas use this domain."

Product touchpoints and the Touchpoints Kit

A touchpoint is a place where configuration or data in one area flows into or constrains another. Some examples an administrator meets constantly:

Workday publishes the Workday Touchpoints Kit on Workday Community. It visually displays the data flows and configuration relationships within Workday - diagrams, heatmaps, and area-by-area details - so that customers and consultants can understand the impact of a design decision on both already-deployed and future areas. When an exam item asks where to look before changing a shared configuration object, the Touchpoints Kit is the intended answer.

Putting the hierarchy together

Workday Tenant
  └── Products (HCM, Financial Management, Payroll, Recruiting, ...)
        └── Functional Areas (Staffing, Core Compensation, Organizations, ...)
              ├── Domains ──────────► secured by a Domain Security Policy
              │     └── securable items: tasks, reports, report fields,
              │        data sources, data source filters, web services
              └── Business Process Types ──► secured by a BP Security Policy
                    └── Business Process Definitions (you configure these)

Read that diagram top to bottom and you have the answer to a surprising share of platform-administration questions. Security policies attach at the domain and business process type level; configuration freedom lives at the security group and business process definition level.