What changed

Every content update is versioned. Select a version to compare it with the one before.

Version 10 → 11

Update

New module on assignments, approvals and governance: SCIM push to applications, group memberships and directory write-back, the organization chart import, approval queues, delegation and owners, access packages and certification campaigns. These topics are part of the MCSA exam and were not covered before.

3 lessons updated

Content update. Enrolled learners were notified.

SCIM push to applications

An application whose vendor offers standard `/Users` and `/Groups` endpoints speaks SCIM 2.0. Such an application needs no connector: Applications → application → tab `Provisioning` → tab `SCIM` pushes the people assigned to it, so the account exists when a user is assigned and goes away when the assignment ends. ### Direction: Monosign is the client Monosign calls the application's SCIM endpoint. It **does not expose a SCIM endpoint of its own**, so another identity system such as Microsoft Entra ID cannot push users into Monosign over SCIM. To bring identities in, use a user source: a directory connector or an import. The `SCIM Entitlement Provider` from the previous lesson is a client too. It reads the other system's SCIM endpoint. ### Settings - `Enable Provisioning`: the master switch. While it is off, no call is made. - `API Url` and `API Key`: the SCIM base address and a bearer token. - `Enable Auto-sync` with `Timing`: a scheduled push, hourly or daily, in UTC. `Force Sync` runs one now. - A push also runs at once when a user is assigned to the application or removed from it, by hand or by a rule. ### What a push does to users A new assignment is looked up on the target, then created with `POST /Users` or updated with `PUT /Users/{id}`. An assignment that becomes **inactive is deleted** with `DELETE /Users/{id}`. Monosign never sends `active = false`, and when the assignment is activated again the target creates a new account with a **new SCIM id**. If the application keeps a user's history only while the account exists, agree with the application owner how that history is exported before a leaver's assignment changes. ::diagram lc-scim-push-lifecycle A user whose default profile has no first name is skipped without a message, so check the profile when one person is missing on the target. ### What a push does to groups The `Groups` you map are pushed as SCIM groups. The push then **deletes every group on the target that is not one of the mapped groups**, including groups that the application's own administrators created. A target group whose `externalId` is not a GUID stops the whole group step. Before you turn on group push for an application that already has groups, list them and decide which ones Monosign will own. ### When something fails SCIM pushes are not listed under Reports → `Provisions`. The service log is the only trace: look for a line such as `SCIM API returned error` with the status code and the response body. The next scheduled run tries again. ### Provision services and user data Some integrations use a provision service with rules, not SCIM. The `User Provisioning Service` evaluates every user against those rules. It treats a user **without an e-mail address, an inactive user or a user whose state is not `Enabled` as matching no rule**, and that deprovisions them. After a directory import, fill in the e-mail attribute before such users are evaluated. > Tip: Run the first push against a test tenant of the application. A delete on the target cannot be taken back from Monosign. ::shot lc-provisions

Approvals, delegation and owners

Preventive triggers and access requests put people in the path of an assignment. Three things decide whether the right person sees a request in time. ### Where a waiting assignment sits A trigger with `Require approval` needs an `Approval workflow` if people are to be notified. With the field empty, the request goes to a **manual queue**: it appears on the trigger's `Approvals` tab and nobody is told. Access is granted only after `Approve`. Either set a workflow or make reviewing that tab part of someone's routine. ### Who can act on a step A workflow step can be assigned to people or, with `Group Approval`, to groups. Group steps are resolved from **current membership** each time the step is read. Someone added to the group can act at once. Someone removed from it loses the row from the `Active` tab of their `Approvals` inbox at once, while rows on `History` stay for whoever acted. Any single current member completes the step, and an empty group leaves it waiting. ### Delegation Security → `Delegations` hands one user's approvals to another for a period: `Assign`, then `User (from)`, `Delegated User (to)` and the start and end dates. The delegate's assignments are added **when a step is created**. A delegation set up afterwards does not attach to steps that are already waiting, so give those steps to another approver by hand. Set delegations before a planned absence, not on its first day. ::diagram lc-approval-routing ::shot lc-delegations ### Owners Many decisions go to "the owner", so owners must be on record. Governance → `Owners` holds who owns an application, user, group, role, permission, resource or AI agent, as a `Direct Manager` or as a `Governance Owner`. Groups, roles and permissions also have an `Owners` tab on their own page. **Applications do not**: assign an application owner under Governance → `Owners` or through the object owners API (`v1.5/object-owners`). Certification campaigns pick reviewers from these rows, and triggers notify them. A campaign reads only the `Owner Type` it is configured for, so an owner recorded with the other type is not chosen. > Tip: When an approval seems to have disappeared, check three things in this order: the membership of the assigned group, whether another member already decided, and whether the flow was cancelled.

Access packages and certification campaigns

Lifecycle automation grants what people need by default. Access packages cover what they ask for, and certification campaigns confirm that what they hold is still right. ### Access packages Governance → `Access Packages` defines bundles that people can request: a title, a `Policy`, a `Lifetime`, an optional `Workflow` for approval and resources from one catalog. `Assigned Object(s)` lists who holds a package. - **Removing an assignment** (v2026.10) revokes the grants that its approved request created. Access the user holds from another source, for example a direct role assignment, stays. A revocation that is refused is logged. - **The policy is locked while in use.** A policy definition that a package refers to can be neither disabled nor removed. Detach it from every package first. Removal is a soft delete, so the history stays. ::shot lc-access-packages ### Certification campaigns Governance → `Certifications` holds definitions: what is reviewed, who reviews, how often and for how many days. A service turns a due definition into a campaign with items and reviewers. - **Reviewers are worked out when the campaign starts**, from the `Reviewer Type`: named users, `User Manager`, a rule or owners. A manager or owner change afterwards does not move the items. A certification manager uses `Reassign` or `Add Reviewer`. - **Nothing escalates.** The only follow-ups are reminder mails and manual reassignment. - **The end date does not decide.** Unless the definition stamps decisions in advance with `Approve All` or `Reject All`, items that nobody reviewed stay undecided and the campaign is simply marked `Completed`. Chase reviewers during the campaign and report undecided items as an open finding. ::diagram lc-campaign-course ### How the pieces fit | Need | Tool | | --- | --- | | Access everyone in a group should have | Automation rule | | Access a person asks for, with approval and an end date | Access package | | Proof that access is still justified | Certification campaign | | Someone accountable to decide | Governance → `Owners` | > Tip: Before a campaign starts, check that every item will have a reviewer: managers filled in on profiles, and owners recorded with the type the campaign reads.