Foundation Data Model Overview
Foundation (FND) is the module that provides shared services consumed by every other module in the platform. It owns no business domain of its own; instead it supplies the infrastructure and starter data that domain modules depend on.
Service areas
| Area | Purpose |
|---|---|
| Tenant users | Maps users to tenants, tracks directory info |
| Reference data | Lookups, countries, currencies, units of measure |
| Navigation | Menu structure, layouts, actions, role assignments |
| Job processing | Async job queue, scheduling, worker management |
| Notifications | Templated notifications and job logging |
| Documents | File/URL storage, attachments, versioning |
| Labels | Scoped tagging system for any entity |
| Auto-code | Automatic code generation (sequences, random) |
| ETL & reports | Data import/export and report definitions |
Common data patterns
Every Foundation entity follows platform-wide conventions:
- Tenant isolation — all data is scoped to the current tenant
- Audit fields — tracks who created, updated, and owns each record, along with timestamps
- Soft deletes — records are deactivated rather than permanently deleted
- Time-bounded validity — optional start and end dates for time-limited records
- Conflict prevention — concurrent edits are detected and prevented
- Metadata — extensible metadata field for custom attributes
- Internationalisation — translatable name and label fields alongside the primary text
Access control
Foundation data uses a layered access control approach:
- Tenant isolation — all data is automatically scoped to the current tenant
- Permission-based access — checked per operation (view, create, update, delete):
- Domain-level permissions for broad access
- Ownership-based access for records you created
- Relationship-based access for shared records
Some areas (ETL templates, report templates, notification templates) use more specific permission checks rather than the general Foundation defaults.
Relationship to other modules
Foundation provides shared services that other modules consume. For example:
- Projects uses lookups for dropdown values, labels for work item tagging, and menus for project navigation
- Worker Relationships uses lookups for configuration enumerations
- All modules use notification templates for email and alert delivery