Enterprise identity compatibility
Google and Microsoft sign-in, MFA, session policy, SAML/OIDC, and SCIM connect to Dayrook-owned tenant, role, recovery, and audit controls.
Administration and governance
Give the right people the right level of control.
Define who can see, approve and change each client environment. Explore shared roles and policies while keeping customer boundaries, sensitive actions and audit records clear.
Security architecture
Visible policy from access to evidenceControl architectureConceptual boundary
- Identity
Role, MFA, and customer scope
- Data
Regional boundary and protected records
- Action
Policy, approval, and stop conditions
- Evidence
Decision, result, and review trail
Every access has a boundary
Useful access. Explicit control.
Apply shared RBAC and attribute policy across modules and machine identities.
Illustrative workflow · explore the steps · no action is executed
01
Define roles and policy
Choose permissions, customer scope, security settings, module access, and regional rules.
Confirm this step for your release, permissions and environment.02
Apply and monitor
Enforce policy through routes, workers, agents, providers, and entitlement-aware navigation.
Confirm this step for your release, permissions and environment.03
Review change and exceptions
Inspect audits, access reviews, overrides, holds, and approval outcomes.
Confirm this step for your release, permissions and environment.Replace policy-by-memory with one visible decision boundary.
Retain allow, deny, approval, and material-failure evidence for review.
Inside the workflow
The work this connects.
- Users and custom roles
- Invite, assign, scope, suspend, revoke, and review users through built-in or custom permissions.
- Identity and session policy
- Configure MFA, enterprise SSO/SCIM, recovery, trusted sessions, and step-up requirements.
- Tenant and module policy
- Control regions, entitlements, feature visibility, automation, and customer-level scope.
- Audit and support access
- Review user, provider, agent, billing, worker, and approved support actions.
- Retention, DSAR, and legal hold
- Coordinate lifecycle controls without treating suspension as deletion.
- Approved tenant branding
- Manage customer-facing identity settings within the governed Dayrook design system.
Try one useful scenario
A removed permission must deny access
Fictional example: a customer removes a contractor’s write role. The contractor then attempts an action on the former client scope. The expected result is denial with no change. Example access rows: client owner—read its client, approve its policy; MSP technician—read that client, write only approved actions; removed contractor—no access. The signed responsibility agreement identifies the accountable party, customer policy constrains the action, and the role grants execution scope; none alone overrides the others. Repeat the denied test after delegation expiry and removal.
Illustrative evaluation scenario, not a recorded product result.What a useful result must show
Check session revocation, delegation removal, approval expiry and the denied-action record from both parties’ permitted views.
Get the evaluation worksheet →Check the support boundaries
- Contractual responsibility and customer policy
- Tenant/client/resource role boundaries
- SSO and SCIM release support
- Support access and approval expiration
Contracts assign responsibility; policy and roles constrain execution. Do not assume a contract overrides a technical denial or that removing one role revokes every offline token.
Check public evidence and availability →Scope, availability and evaluation details
A policy cannot grant a capability the connected provider, operating system, plan, or release does not support.
Certification claims still require the relevant external assessment and approval.
The proposed $99 monthly model includes the target product scope for evaluation, unlimited technicians, unlimited customers, and the first 50 managed devices. Final terms require confirmation. See transparent pricing →
Review full environment and integration scope
One policy boundary across modules
Endpoint, service, backup, Digital Vault, network, cloud, AI, and infrastructure actions reuse the same tenant scope, permissions, entitlements, step-up, regional, and audit decisions.
Governance is enforced by the owning route, service, worker, agent, or collector rather than by interface state alone.
Questions, answered
Before you choose your next step.
Can we create custom roles?
Target design: Custom roles can assign module-level read or write access while tenant, customer, and action gates remain enforced.
Does Dayrook support SSO and SCIM?
Enterprise identity includes SAML/OIDC SSO and SCIM readiness alongside first-party sessions and MFA.
Can support impersonate a customer silently?
No. Support-safe access requires authorization, reason, scope, time limit, and an audit trail.
Can a legal hold block deletion?
Target design: Legal hold and active privacy or contract review can prevent purge until the governing condition is resolved.