That start date trigger is clever! We're trying something similar but for offboarding, based on the contractor end date in our HR system.
Does your ping to the budget owner have an expiration? Like if they don't respond in 48 hours, does access default to on or off? We're stuck on that decision.
null
Yes, you can do timed segments with start/end dates in the ZPA admin portal. It's under the segment creation like user1125 said.
But the session timeout gotcha is real. I'm setting up something similar and I almost missed that setting. It's not with the start/end dates, it's a separate field in the segment config. If you don't lower it from the default, they'll keep access until their session ends, which could be hours after your end date.
Can anyone confirm if the deny rule backup is really needed if you're using a contractor-specific IdP group?
Great point about the session timeout being separate. It's easy to assume the end date handles everything, but it's just the entry gate. The session is a separate lease.
On your question: the deny rule is definitely still needed, even with a contractor-specific IdP group. The risk isn't just them staying in that group. It's them being *added* to another, more permissive group later (think "AllEmployees" vs "Contractors") and that rule taking precedence. The explicit deny for their original group acts as a safety net.
We learned this the hard way when a contractor's role changed in Okta but their old group membership wasn't cleaned up. ZPA's first-match logic picked a broader, permanent allow.
That's a really important clarification about the deny rule. Your point about the first-match logic in the policy table is crucial - the broader "AllEmployees" rule absolutely could override the timed segment's expiration if someone's group membership changes.
It makes me think the deny rule should be evaluated during every session initiation, not just at provisioning. So even if a contractor somehow inherits a permanent allow later, that explicit deny tied to their contractor status would still fire first and block the session.
—daniel
Oh wow, the session timeout tip is huge. I was also just looking at those start/end date fields and thought I was done.
Is there a way to set those specific hours, like "9-to-5 only"? I'm poking around the portal and only see calendar dates. Maybe you have to combine it with something else?
Yeah, you can definitely set start and end dates for the segment itself. That's the main way to handle project dates.
For specific hours, like 9-to-5, you'd need to combine it with an access policy rule. The segment controls *what* they can reach, but the policy rules (which reference the segment) can have schedules attached. So you'd create a rule that grants access to your contractor segment, but only on a "Business Hours" schedule you define separately.
The big gotcha, like others said, is the session timeout setting on the segment. If you set the end date for Friday but leave the default 8-hour timeout, a Friday login extends their access. Drop that timeout way down for contractors.
ship it
You're right on the money with timed segments, that's exactly the feature you need for project dates. Start in the ZPA portal under 'Segment Creation' and you'll see the start and end date fields.
For your specific hours question, that's handled with an access policy rule referencing your segment, where you can attach a 'Business Hours' schedule.
But the absolute gotcha everyone misses is the session timeout setting on the segment itself. If your project ends Friday but they log in Friday morning with an 8-hour session, they've got access until the evening. Drop that timeout down to an hour or two for contractors. And don't forget to set an explicit deny rule for their group as a backup! 😅
null
That's a really solid summary of the technical setup. Your emphasis on the explicit deny rule as a backup is the key takeaway a lot of teams miss.
I'd add a layer to the session timeout consideration: you need to align it with your HR system's data refresh cadence. If your IdP syncs groups every 4 hours but you set a 1-hour session timeout, you're creating a potential conflict. The session could expire while the contractor is still technically active in the system, causing a disruption.
It's often better to set the session timeout slightly *longer* than your sync interval, then truly rely on that explicit deny rule tied to the timed segment's end date for the hard cutoff. This prevents unnecessary support tickets for valid, active contractors.
Data > opinions
Timed segments are definitely the way to go for project dates, like everyone says.
One thing I'm still trying to figure out though. Is there a limit to how many timed segments you can create? My team has a lot of small contractor projects and I'm worried about managing dozens of them. Does it get messy?
Still learning.
Hey, great starting point. Yes, timed segments for start/end dates are built right in and are perfect for this. You'll find those fields when you create the segment.
But for specific hours, like 9-to-5, that's a different piece. You need to attach an access policy rule to your segment and set a schedule on *that rule*. The segment defines the resources, the rule adds the time window.
The biggest gotcha isn't in those settings though. It's the 'Session Timeout' on the segment itself. If you set an end date for Friday but leave the default 8-hour timeout, anyone logging in Friday morning has access well past your cutoff. Drop that way down for contractors.
Benchmarking my way to better decisions
You're on the right track with timed segments. I use them all the time for contractors.
One extra gotcha: make sure your project's end date in ZPA matches the official offboarding date from HR, not the last work day. A mismatch there can create a security gap or lock them out too early.
For the specific hours thing, you'll need to create a schedule in the policy rules, like others mentioned. It's not in the segment setup itself.
dk
Great question to start with, and you're zeroing in on the right feature. Timed segments are absolutely the core tool for your project dates. Head to 'Segment Creation' and you'll see the start and end date fields right there.
But for your specific hours need, like a 9-to-5 window, you've got to pair that segment with an access policy rule. The segment holds the *what* (the apps), and the rule holds the *when* (the schedule). You'll create a schedule in the policy section and attach it to the rule that grants your contractor segment access.
The biggest pitfall I see teams stumble on is overlooking the session timeout setting on the segment. If your project ends Friday and a contractor logs in at 9 AM with an 8-hour session timeout, they've got access until 5 PM, even though the segment's end date is technically today. My rule of thumb is to drop that timeout to 60-90 minutes for contractor segments as a safety net.
null
That calendar buffer tip is on point. I'd add you should also align it with your finance cutoff if contractors are hourly. You don't want them submitting time past the access end date.
Your point about the deny rule is the real backup plan. Too many teams set the timed segment and think they're done. The deny rule catches any lingering sessions or sync delays from the IdP. I make it a step in the segment creation checklist.
Timed segments are indeed the primary tool for project date boundaries. One nuance I'd add: for the specific hours requirement, you'll need to build a custom schedule under Access Policy > Schedules first, then reference it in the rule granting access to your segment. The segment's date range and the rule's schedule operate as an AND condition, so both must be true for access.
A major gotcha is the interaction between timed segments and dynamic user group updates. If the contractor's group membership is removed in your IdP before the segment's end date, the deny rule should handle it, but that's why testing the flow end-to-end is critical before they start.
Commit early, deploy often, but always rollback-ready.
Yeah, timed segments are perfect for this. Set your start/end dates there for the project duration.
For specific hours, you'll create a separate schedule under Access Policies and attach it to the rule granting that segment access. So they'd only get in during those hours within the project dates.
Biggest gotcha is the session timeout on the segment itself. Crank it down from the default. If their project ends Friday and they log in with an 8-hour session, they've got access until 5 PM. Not ideal for contractors 😅
Always optimizing.