1. Start with the Organization Level

An organization in Optimality represents a tenant – a fully isolated environment with its own users, data, and configurations.
This is your foundation, where you define company-wide standards that everything else builds on.

Each organization contains:

• Standard Process Library – A curated repository of approved workflows, templates, and process structures.

• Standard Master Data – Your core reference data: activity types, deliverable categories, milestone classes, etc.

• User and Permission Management – Defines who can access what within that environment.

While each organization is isolated, Optimality gives you granular control over who can access information across endeavors within the same organization.
That means it’s completely possible, and often preferable, to host multiple endeavors, joint ventures, or business units within a single organization, as long as they share the same standard process library and overarching data definitions.

You only need to create separate organizations when there’s a need for:

• Distinct user bases that should never have visibility into each other’s work

• Unique permission models that can’t be handled through team or endeavor-level access control

• Fully independent standard process libraries and master data

This level of separation is usually reserved for entirely different companies or entities that don’t share any operational framework, not just for different projects or endeavors under the same umbrella.

💡 Best Practice:
Keep a single organization whenever possible. Separate organizations only when you’re managing fully distinct entities with their own governance structures.
Remember, at this time, Optimality doesn’t link data between organizations, so each tenant remains completely siloed.

‍

‍

2. Define Endeavors Thoughtfully

Within an organization, endeavors represent major units of work: projects, programs, initiatives, or portfolios.
Each endeavor has its own set of:

• Activities and milestones

• Content and tasks

• Teams and sub-teams

• Commitment plans

However, all endeavors share the same organizational master data and standard process library.

You’ll want to create separate endeavors when:

• You’re managing distinct endeavors that require unique teams and schedules

• You need unique sets of master data or want to avoid filtering from a large, shared list

• You’re approaching the scale limit for the number of activities in a single endeavor

• You want to track commitments or performance independently between teams or endeavor types

Currently, endeavors don’t create direct dependencies between activities across endeavors, though cross-endeavor reporting is available for portfolio-level insights.

💡 Best Practice:
Use separate endeavors for distinct projects or portfolios that require different team structures, commitment plans, or data configurations.
If multiple projects/sub-projects share the same people and master data and have multiple dependencies between them, it’s often better to keep them in a single endeavor and use filtering instead to see them separately.

‍

‍

3. Structure Teams and Sub-Teams for Collaboration and Control

Teams define how people are grouped within an endeavor. They serve multiple purposes:

• They can be used to swimlane the Activity Flow Diagram.

• They define who participates in individual commitment plans.

• They govern permissions for activities, content, and tasks.

You can create:

• A single team for simple endeavors, where everyone participates in one shared commitment plan.

• Multiple sub-teams when you want to run separate commitment plans or manage different scopes of work within the same endeavor (e.g., design, procurement, and construction teams).

💡 Best Practice:
Start with one main team to establish commitment rhythm and expand into sub-teams as needed.
Remember, each sub-team can have its own commitment plan, giving you flexibility without losing visibility.

‍

‍

4. Manage Master Data for Consistency and Flexibility

Master data is one of the most important layers in your Optimality structure – it drives consistency across endeavors and connects to your Standard Process Library.

There are two levels to consider:

• Organization-Level Master Data: Centralized, reusable definitions. These are the source of truth and should be used whenever possible to maintain standardization.

• Endeavor-Level Master Data: Localized data that’s specific to one endeavor or use case. These are useful when endeavors require variations that shouldn’t apply globally.

When you pull a process from the Standard Process Library, it automatically references your organization’s master data definitions. You can also tag endeavor-specific master data to activities before importing a process and Optimality will duplicate and apply that data consistently across all imported items.

💡 Best Practice:
Always start from organizational master data. Only create endeavor-level master data when it’s truly endeavor-specific. This ensures you maintain consistency across your instance and leverage the intelligence built into your standard processes.

‍

‍

5. Use Standard Processes to Maintain Lineage and Reuse

Another foundational best practice is to leverage Standard Processes whenever you anticipate repeating similar work patterns, whether within a single endeavor or across multiple endeavors.

If an endeavor is going to perform the same sequence of activities repeatedly, or if multiple endeavors are expected to follow the same workflow, it’s best to create that structure as a Standard Process within your organization’s Standard Process Library, then import it into each endeavor as needed.

This approach has several key benefits:

• Maintains Lineage: Each activity imported from a Standard Process retains a link back to its original source, allowing you to trace where that activity originated.

• Improves Analytics: Because lineage is preserved, Optimality can track how frequently a Standard Process is used and evaluate performance metrics across all endeavors that have applied it.

• Supports Continuous Improvement: You can see how users modify and adapt standard activities over time, helping identify best practices and potential updates to your organizational standards.

• Prevents Duplication and Drift: Copying and pasting activities manually creates disconnected duplicates, breaking lineage and making it impossible to analyze how that process performs across endeavors.

💡 Best Practice:
Always build recurring workflows as Standard Processes, then import them into endeavors.
This keeps your structure clean, your data connected, and your performance insights meaningful.

6. Permissions: Built into Your Structure

Permissions in Optimality are closely tied to your team and data hierarchy.

• At the organization level, admins define global access roles.

• Within each endeavor, team membership determines who can view, edit, or commit to specific activities, tasks, and content.

• At the artifact level (activities, tasks, and content), tagging a team or sub-team automatically assigns editing rights.

💡 Best Practice:
Design your team structure first—permissions naturally follow from it.
Avoid overcomplicating the permissions; start basic (just admins and moderators) and expand as needed.

‍

‍

7. When to Split vs. Share: Common Scenarios

8. Bringing It All Together

Here’s the summary of how it all connects:

• Organization = Foundation. Defines your permissions, master data, and process library.

• Endeavor = Workspace. A self-contained environment for related work.

• Team/Sub-Team = Collaboration Unit. Controls who’s doing what, where, and when.

• Master Data = Common Language. Keeps everything standardized across your organization.

• Standard Processes = Reusable Blueprints. Maintain lineage, consistency, and measurable improvement.

Getting these layers right ensures your Optimality instance scales naturally without rework, duplication, or confusion down the line.

‍

9. Final Thoughts

Structuring your Optimality instance isn’t just a technical setup, it’s a strategic decision. The right structure enables collaboration, transparency, and continuous improvement.

Start simple. Align your organization and endeavors with how your teams actually deliver work. Keep your master data standardized, use Standard Processes for repeatable workflows, and let your team hierarchy drive permissions.

As your organization grows, your Optimality structure can grow with it—efficiently and without friction.

‍

‍

Next Steps

• Review your current organization and endeavor structure against these guidelines.

• Document your standard master data and decide what should remain organizational vs. endeavor-specific.

• Identify repeatable workflows and create them as Standard Processes.

• Plan your team and sub-team layout with commitment planning in mind.

• If you’re onboarding a new organization, schedule a setup session with your Optimality implementation lead to ensure alignment.

‍

Need Help Structuring Your Instance?

If you’re setting up a new organization or reconfiguring your existing Optimality instance, our team is here to help. Whether you just need guidance on best practices or hands-on consulting to design your structure, we’re available to make sure your setup is efficient, scalable, and aligned with your goals.

You can reach out to the Optimality team anytime for assistance or to schedule a working session — we’ll make sure your organization gets started on the right path.