Process integration / 08
Create users. Grant and revoke access deliberately.
A new employee needs access to several applications. A team change alters roles, and a departure requires access removal. We connect authoritative personnel data to a controlled process for these changes.
The starting point
A user account is only part of access management.
HR owns employment status and start dates, a directory owns identity and business applications own specific roles. License assignment, group membership and privileged access follow different rules. A changed email address must not create a new person.
We assess available APIs and provisioning standards such as SCIM where supported. Microsoft Graph may be a suitable interface in Microsoft environments; tenant type, supported actions and required permissions are assessed specifically.
What DataSource delivers
Identities. Role model. Lifecycle.
Identities
Define a stable person key and account mappings. Treat rehires, external staff and name changes as distinct cases.
Role model
Derive technical actions from approved business roles. Handle privileged access through separate approval rather than copying it from a free-text field.
Lifecycle
Translate onboarding, changes and offboarding into executable steps. Confirm results per target system and make incomplete access removals visible.
Person-ID: EMP-1042
Status: aktiv
Rolle vorher: Vertrieb
Rolle danach: Einkauf
1. Genehmigung prüfen
2. Nicht mehr erlaubte Gruppen entfernen
3. Genehmigte Zielgruppen setzen
4. Zielzustand je Anwendung bestätigenTechnical scenario / Illustrative example
A team change removes old access before new access takes effect.
Illustrative workflow for an approved role change. The ordering depends on the security model. Existing sessions, tokens and separately managed access need to be considered during offboarding.
Example data and proposed rules. The actual interfaces and business rules are assessed for your project.
Error handling, security and operations
Failures and revocation: validate and operate.
Failures and revocation
An unreachable target must not give the impression that offboarding is complete. Prioritize and retry outstanding access removals and report them to the agreed owner.
Least privilege
Restrict technical accounts to required actions. Depending on the action, Microsoft Graph may require application permissions and administrator consent.
Traceability
Record changes, approvals and results for auditability under the agreed design. Minimize HR data and define retention and access deliberately.
Technical questions
Details that matter before implementation.
Provisioning · IAM · Roles · Approvals · Onboarding · Changes · Offboarding
Can HR alone determine all access rights?
HR often provides the triggers. Business role ownership and approval of privileged access remain with the designated responsible parties.
Is disabling a directory account enough during offboarding?
Not always. Local accounts, existing sessions and API tokens may require separate actions. This is checked per target system.
Can an existing IAM system remain in place?
Yes. We can add a missing source or target adapter, or a narrowly scoped workflow, without replacing the existing role model.
For technical clarification
Start with your actual workflow.
Identify authoritative HR data, target systems, the role matrix and current onboarding and offboarding processes. Anonymized cases involving a team change or rehire are useful.
In our initial discussion, we clarify available access, data ownership and a narrowly scoped first data flow. We then agree on scope, responsibilities and commercial terms.
Anonymized examples are enough to get started. Please do not send passwords, tokens or personal data from production systems in your initial inquiry.
Related challenges
Your next connection in context.
Proxmox API & automation
VMs are requested through tickets, cloned manually and then maintained in several lists. We develop a defined provisioning workflow between your request, Proxmox VE and downstream systems.
Process webhooks reliably
An event arrives and needs to trigger an action in the next system. Duplicate delivery, delays or an unavailable target API turn this into an operational process. We develop that workflow with uniquely identified events and verifiable effects.
ERP and CRM interfaces
Sales and accounting work with the same customer for different purposes. DataSource connects the supported interfaces and clarifies which data is transferred, and when, between prospect, customer and debtor records.
Technical references
Official documentation, reviewed on October 6, 2026. Suitability depends on the specific installation and version.