Implementation Team Offboarding and Ownership Risk

On this page

• Why this is a platform risk
• What the tenant looked like
• What breaks, object by object
• The other issues
• A sequence that keeps the platform running
• Handover acceptance
• Symptoms after an owner leaves
• What to do from day one
• Sources and how far to trust them
• Actions

Every implementation ends with the people who built it leaving. In ISC that departure is not an HR formality, because the platform ties objects, credentials, notifications and knowledge to named individuals. When those individuals are disabled or removed, workflows can stop, approvals can stall, sources can lose their owner, scripts can lose their tokens and the runbook can turn out to live in someone's head. This page describes what the tenant looked like at the end of the program, what breaks and why, and a sequence for leaving a platform that keeps working. Counts are rounded or exact from a read-only tenant dump, and no names appear.

Why this is a platform risk

An ISC object is rarely independent of a person. Four kinds of tie exist:

The implementation team is the worst case, because it created most of the platform and holds a disproportionate share of all four.

What the tenant looked like

At the end of the program the tenant held the following. The dump is a snapshot from the final weeks.

Three things stand out.

1. Ownership was concentrated. One identity owned nine in ten access profiles and most workflows. That is typical of a build done by a small team, and it is exactly what makes the departure dangerous.
2. Credentials were personal. The tokens were created by individuals, and several were the sort of convenience credential (a script, an editor extension, a REST client) that outlives its purpose.
3. There was no safety net. With no fallback approver and no reminders, an approval addressed to a removed person simply waits. The same is true of a certification.

The administrator identities, too, came from a small delimited file with no appliance, not from the HR feed. Identities loaded that way are not touched by the HR leaver automation. Offboarding the implementers' own administrator accounts is a manual task unless you plan it.

What breaks, object by object

Disable and delete are different

From SailPoint's identity documentation:

• Disabling an identity removes sign-in to the platform immediately. An active session continues until it ends. It does not disable the person's accounts in source systems or revoke access there. User levels are kept.
• Deleting an identity removes its correlated accounts from the identity (they are not deprovisioned at the source). Identities that own sources, roles, access profiles or applications cannot be deleted, nor can reviewers of active certifications. Assign new owners and reassign the reviews first.
• A deletion is only temporary if the person still exists in an authoritative source, because the next aggregation can recreate the identity with a new internal identifier. The person then has to be invited again and given back any elevated rights.

So the order is: reassign everything, then disable, then observe, then delete if you must.

The other issues

• Credentials the team knows. Source credentials and client secrets that only the implementers have seen. Workflow secrets can only be created in the UI, so a rotation needs a person who can do it and has the vault.
• Local material. Tenant dumps, exported rules and workflows, scripts and workbooks on laptops, some containing credentials. These must be found, handed over or destroyed. The campaign tool's workbook holds an API client and a file server login.
• Tokens in tools. Editor extensions, REST clients and scripts each held a token. Unused tokens are not harmless: they are valid until expiry.
• Several tokens expiring together. Six tokens carried the same expiry date, which suggests a bulk update. They will all stop on the same day, and whoever remembers them will have left.
• Support and vendor channels. Support cases, expert services contacts, community accounts, the ITSM queue the integrator joined, mailing lists and chat channels.
• Approvals and notifications addressed to individuals. Eleven personal-looking addresses sat in workflow definitions, and the approval fallback was empty.
• Hard-coded identifiers. Workflows reference objects by identifier. Rebuilding or transferring them changes those identifiers.
• Service desk ownership. Who now answers "the manager never got the form" at two in the morning.
• Contract ends but access does not. Implementation accounts in downstream systems (directories, the ITSM tool, application consoles) are not removed by ISC. Offboard them in those systems.
• Support access. SailPoint's own support and services tokens are removed when tenant access expires. Re-grant it deliberately if you will need help.

A sequence that keeps the platform running

1. Inventory (about 90 days before)

Build an owner register: every object, its type, its owner, a deputy and a review date. Produce it from the API, not from memory. The script below groups by owner and writes a file you can review.

import csv, json, os, time, urllib.request

TENANT = os.environ["ISC_TENANT"]
TOKEN = os.environ["ISC_TOKEN"]
BASE = f"https://{TENANT}.api.identitynow.com"

# path, name of the owner field in the response (names differ by object type; check each)
ENDPOINTS = [
    ("/v2025/sources", "owner"),
    ("/v2025/access-profiles", "owner"),
    ("/v2025/roles", "owner"),
    ("/v2025/workflows", "owner"),
    ("/v2025/form-definitions", "owner"),
    ("/v2025/governance-groups", "owner"),
    ("/v2025/campaign-templates", "ownerRef"),
    ("/v2025/saved-searches", "ownerId"),
    ("/v2025/scheduled-searches", "ownerId"),
]

def get(path, offset=0, limit=250):
    req = urllib.request.Request(f"{BASE}{path}?limit={limit}&offset={offset}",
                                 headers={"Authorization": f"Bearer {TOKEN}"})
    for _ in range(5):
        try:
            with urllib.request.urlopen(req) as r:
                return json.load(r)
        except urllib.error.HTTPError as e:
            if e.code == 429:
                time.sleep(int(e.headers.get("Retry-After", "5")))
            else:
                raise
    raise RuntimeError("rate limited")

def owner_of(obj, field):
    v = obj.get(field)
    if isinstance(v, dict):
        return v.get("id"), v.get("name")
    return v, None

with open("owner_register.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["type", "object id", "object name", "owner id", "owner name"])
    for path, field in ENDPOINTS:
        offset = 0
        while True:
            page = get(path, offset)
            if not page:
                break
            for o in page:
                oid, oname = owner_of(o, field)
                w.writerow([path.rsplit("/", 1)[-1], o.get("id"), o.get("name"), oid, oname])
            if len(page) < 250:
                break
            offset += 250

Notes: some endpoints do not take limit and offset, and some are in the beta namespace, so check each against the current API reference. Add the personal access tokens (listed per owner by an administrator), the OAuth clients and the scheduled searches' recipients. Sort the result by owner and count objects per departing person: that count is your effort estimate.

Also search the definitions for hard-coded addresses and identifiers:

grep -rnoE "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[a-z]{2,}" exported-workflows/ | sort | uniq -c | sort -rn
grep -rnoE "\b[0-9a-f]{32}\b" exported-workflows/ | cut -d: -f3 | sort | uniq -c | sort -rn

2. Design the target ownership model (about 75 days before)

The service identity must be governed: record who holds its credentials and its multi-factor authenticator, keep break-glass credentials with named people, and review it quarterly. Some of the community material suggests the platform's service-account approach is being superseded by newer machine identity features, so confirm what your release recommends.

3. Reassign (about 60 to 30 days before)

Transfer in this order, testing after each group:

1. Governance groups: add members first, then change owners.
2. Access profiles, roles, entitlements, applications. Use the list endpoints filtered by owner and update the owner. Do it in bulk, scripted, with a before and after count.
3. Sources. Change the owner on each. Check that none of the owners is also an account holder on a source you will reset.
4. Workflows. A workflow must be disabled before its owner is changed. Assigning it to another administrator generates a new personal access token and a new owner. Do one at a time, run it, check an execution.
5. Forms, launchers, saved and scheduled searches. Transfer, then verify that a scheduled search still produces its output and its recipients still receive it.
6. Campaign templates and active certifications. Reassign reviews and templates. Complete or reassign active campaigns before disabling a reviewer.
7. Tokens and clients. Create replacements under the service identity, switch each consumer, confirm it works, then revoke the old one. Record the new expiry.

The community has built workflows that react to a leaver by finding what the person owned and asking the manager for a new owner. Useful ideas, but note their limits (loop caps, search index lag) and that workflow reassignment may reassign requests, not ownership. Test them. There is also a product connector designed for governance reassignments, which may fit if you want this to be permanent.

4. Make it repeatable (about 30 days before)

• Keep the owner register current, with a quarterly review.
• Add a monitor for objects whose owner is inactive, disabled or missing. A search for identities with an inactive lifecycle state that still own things is the simplest one.
• Add a monitor for workflow execution failures with authorisation errors.
• Add a monitor for tokens approaching expiry or not used for a long time.
• Schedule the reassign automation if you use it.

5. Shadow period (about 30 days before)

Have the receiving team run the platform while the implementers are still there. They should exercise every runbook (the hypercare page lists them) and make one real change safely each. Use the findings to correct the documentation.

6. Disable, observe, then delete (cutover and the 30 days after)

• Disable the identities, do not delete them. Disabling stops sign-in and (according to community reports) their tokens, but it does not touch their accounts at source systems, so offboard those in the directories and applications themselves.
• Observe for 30 days. Watch the workflow failure rate, scheduled search output, joiner and leaver volumes, aggregation freshness, and approvals waiting.
• Delete only when nothing owns anything, no active certifications name them, and the owner register shows no references. Remember a person who is still in an authoritative source can reappear as a new identity.
• Remove vendor access: support cases, expert services, community and chat memberships, the ITSM queue.

Handover acceptance

Treat the handover as a deliverable with a signature, not an assumption.

Symptoms after an owner leaves

What to do from day one

Offboarding is cheap if you start the project with the end in mind.

• Create workflows, forms and sources under the service identity from the start, not under a personal account that you later have to transfer.
• Keep a live owner register from the first sprint.
• Use governance groups for ownership of access items.
• Prefer shared mailboxes in every template and workflow.
• Give every token a purpose, an owner, an expiry and a review date, and stagger expiry dates.
• Keep secrets in the vault with two people able to retrieve them.
• Write the runbook as if the author were already gone.
• Plan the offboarding date at kickoff and put the 90 day inventory in the project plan.

Sources and how far to trust them

• Building a workflow: owner, personal access token, orphaned workflows, reassigning to another administrator, using an account that will not expire. Official.
• Working with identities: what disabling and deleting an identity do, and the ownership and reviewer restrictions on deletion. Official.
• Managing API keys and personal access tokens: tokens belong to their creator, cannot exceed the owner's access, ten per user, default six month expiry, API clients are not tied to a person. Official. It does not say what happens to a token when its owner is disabled.
• Community threads, which are not official: a reply that disabled identities' tokens are disabled too and are not restored on re-enable (PAT behaviour); workflow-owner 401 errors and the owner-switch workaround (workflow owners); reassigning owned objects with workflows or the governance connector (reassign owners, owner termination); and service identities as owners (service accounts).

What we could not confirm: what a form does when its owner is removed, whether scheduled searches keep running for a disabled owner, and what happens to a token when its owner is deleted. Test these on a sandbox identity before you rely on an answer.

Actions

• Produce the owner register now and count objects per implementer.
• Name the service identity, its credential and authenticator custodians, and the break-glass holders.
• Reassign in the order above, workflow by workflow, with a test after each.
• Replace personal tokens and addresses with service-owned, shared ones.
• Add the owner-inactive, workflow-failure and token-expiry monitors.
• Run a 30 day shadow period and a 30 day observe period.
• Disable first, delete last, and offboard accounts in the downstream systems yourself.
• Sign the handover against the acceptance table.