Credential administrator handover: a practical checklist

A new credential administrator needs more than an invitation to the account. They need to know which award rules are approved, what is waiting to be sent and who can resolve the next exception. Use a handover record and a practical walkthrough to transfer those responsibilities together.
This checklist is for a staff change within an existing certificate or badge program. It offers a suggested operating process, not a claim that a particular handover will prevent every interruption. If you are changing vendors, follow the separate credential platform migration guide.
Define what the new administrator will own
Start with the work, then match access to it. Preparing recipient lists, approving eligibility, sending awards, maintaining integrations and paying invoices can belong to different people. An incoming coordinator does not automatically need to become the full account owner.
In Sertifier, Users & Permissions supports invitations and separate access controls for credential operations, integrations, analytics and account administration. The same documentation explains full account ownership transfer. Use that procedure when full ownership is intended; do not treat it as the default permission set for every colleague.
Write the outgoing owner, incoming owner, effective date and backup contact beside each responsibility. For an unresolved responsibility, name the person who will make the assignment. A blank cell is an open task, not a completed transfer.
Prepare a program handover record
Keep this record in your organization’s approved workspace. Link to controlled source records rather than copying learner information into a widely shared document.
- Program definition: approved award name, eligibility criteria, current version and the person authorized to approve changes.
- Next issuance: cohort or campaign reference, intended send date, current state and remaining approval. Separate drafts from anything already scheduled or sent.
- Approved materials: current certificate or badge design, notification copy and the source of recipient data.
- Open exceptions: unresolved corrections, delivery questions and held awards, with an owner and next action for each.
- Connected systems: integration purpose, responsible technical contact and the approved procedure for testing or changing it.
- Account continuity: billing contact, support route and where authorized staff maintain the account recovery process.
- Evidence of completion: walkthrough date, tasks demonstrated, remaining gaps and who accepted the handover.
Do not put passwords, private API keys or recovery codes in this record. Refer to the approved access process instead. Sertifier’s permission guide notes that integration access includes viewing API keys, so consider that exposure when choosing who needs the permission.
Walk through the next real task
Ask the incoming administrator to explain the next cohort using their own account. Can they find the approved criteria, identify the correct draft and show which approval is still missing? Let them perform a permitted preparation task using synthetic data in an approved test area. Do not send real credentials merely to prove that a button works.
Then review an exception together. Use an anonymized case or a fictional scenario: a recipient asks for a name correction after issuance, or a cohort list contains someone whose completion has not been approved. The incoming administrator should identify the decision owner and the existing procedure before acting.
Example handover note
Fictional scenario: The next workshop certificates are prepared, but the attendance owner has not approved the final list.
Incoming coordinator: Locate the saved draft and approved design. Keep issuance on hold.
Program owner: Resolve the attendance list and record approval.
Completion evidence: The incoming coordinator can explain the hold and identify the person who can release it.
This demonstrates understanding of a pending task. It does not demonstrate a successful live issuance or prove the entire program is ready.
Check integrations before removing the outgoing user
Ask the technical owner whether any connected workflow depends on the departing person’s access or personal account. Record the answer for each connection. Do not assume that inviting a new administrator transfers ownership of an external LMS, CRM or workflow service.
If a dependency needs changing, use that system’s approved change process and test the affected workflow. A staff handover is not permission to rotate every secret, replay old events or resend a cohort. Our credential automation guide covers the broader event, validation and recovery design.
For a planned transition, verify the incoming user’s access and required responsibilities before removing the outgoing user according to your organization’s policy. If immediate removal is required for a security reason, follow the security team’s process and assign an authorized interim owner; do not retain access just to finish a checklist.
Close the handover with observable evidence
Record what the incoming administrator actually demonstrated. “Invitation sent” and “handover complete” are different states. Keep unresolved access, ownership or workflow questions open with a named owner and due date.
After the next authorized issuance, review the result through the program’s normal delivery and verification checks. Confirm who handles recipient questions and update the handover record with anything the walkthrough missed. Do not change award criteria, backdate records or reissue existing credentials simply because the operating team changed.
If you already use Sertifier, review the current permission and ownership instructions with your account administrator. If you are choosing a platform for a shared credential program, discuss your team workflow with Sertifier and ask to see how the required responsibilities map to available access controls.



