Hello again,
Thank you for the detailed follow-up. Your observations are spot-on, and providing this extra context about your reliance on the standard Modern UX views is incredibly helpful. Let's unpack your questions, as these are common design crossroads for organizations maturing their resource management processes in Clarity.
1. Using the Standard Modern UX Staffing Views You are absolutely correct to call out the limitation with standard views. My previous suggestion regarding calculated measures is a best practice for MUX Reports or external BI tools (like Power BI).
Because your teams rely on the out-of-the-box MUX Staffing workspace ("Capacity vs Demand by Resource"), we cannot inject custom is_role logic into those standard charts. A standard filter would indeed drop the demand rows you need to see. Therefore, your instinct is correct: to achieve your desired outcome in MUX, we must drive Role Capacity to zero at the data level.
2. Clarifying Date of Hire (DOH) & Date of Termination (DOT) There is a subtle but important distinction in how Clarity's staffing engine handles these dates:
- Demand (Allocations): DOH and DOT do act as boundaries here. When you staff a resource, the system will automatically constrain their team allocation to fall within their active employment dates.
- Capacity (Availability): DOH and DOT do not dynamically adjust a resource's underlying availability curve (the time slices that generate your capacity reports).
This is why a terminated contractor still inflates your overall capacity if their availability wasn't explicitly zeroed out.
Best Practice: To accurately drop terminated contractors from your capacity views, their actual Availability Curve must be end-dated. Organizations typically automate this via a XOG integration with their HR system or a Clarity process triggered during offboarding.
3. Setting Role Availability to 0 (Bypassing MUX Validation) Modern UX enforces stricter frontend UI validations (Availability > 0) than older interfaces to prevent accidental data entry errors. Organizations that successfully run with 0-availability roles typically bypass this frontend validation using supported methods:
- Classic UX: The Classic UI often permits updating availability to 0 where MUX blocks it.
- XOG / REST API: You can push an availability curve of 0 to a role programmatically. This is fully supported and circumvents the MUX UI restriction.
Note: We strongly advise against using database scripts for this. Bypassing the application layer prevents the Availability Curve BLOB from calculating, which will corrupt your capacity time slices.
4. The "Zero-Working-Day Calendar" Approach Since MUX blocks 0 availability in the UI, assigning roles to a dedicated Base Calendar with zero working days is a highly creative and common alternative. You leave the role's Availability field at 7.5 hours/day (satisfying MUX), but because the calendar has 0 working shifts, the time-slicing engine generates exactly 0 Capacity.
- The Caveat: If your project managers use the auto-scheduler (Gantt) and assign tasks only to unstaffed roles, the scheduling engine looks at the assignee's calendar. A calendar with zero working days will cause task duration calculations to fail or stretch infinitely. If you don't auto-schedule against roles, this is a very viable option.
Given your requirements, driving Role Capacity to 0 is the right path forward for your standard MUX views.
If your teams do not actively use the Gantt auto-scheduler for role-based tasks, the Zero-Working-Day Calendar is often the easiest to implement and maintain. If task scheduling is a factor, we recommend using XOG or the REST API to update your role availability curves to 0.
I hope this helps clarify the underlying mechanics and gives you a clear path forward.
Enjoy your vacation, and we look forward to hearing which approach you decide to take!