6.16.26 - Employee Deactivation and Ark User Access SOP
Overview of Employee Deactivation Procedures
Objective: To conduct a comprehensive walkthrough of the employee deactivation process, focusing on removing access across multiple systems including ARC, QuickBooks Online (QBO), Amalgam, and the Standish internal databases (NAV and CRM).
Key Participants:
Lisa: Lead instructor and deactivation processor.
Gus: Trainee (Intern/New Hire transition).
Luke: Manager/Reviewer providing context on legal and licensing requirements.
Subject of Deactivation Example: Kashish Katari.
Core Timing Policy: Deactivations are processed at local time for the exiting employee. In the example provided, the employee is in the Eastern Time Zone; therefore, deactivation begins as soon as it is ET.
Initiation and Pre-Exit Review
Notification Sources: Requests typically arrive via automated notifications. Common status messages include "exit date updated" or "new employee notice given." These notifications originate from two different tracking sheets but are treated identically for processing purposes.
Case Study Specifics (Kashish Katari):
Notice Given: June 25.
Exit Date: July 2 (07/02/2024).
Ticket Reference: 31560.
Macro Tooling: Internal notes are managed using macros within the ticketing system.
Macro 1: Pre-Exit Review: Used when the notice is first received. The processor checks all current access levels and notates what must be removed on the exit date.
Macro 2: User Access Exit Removal: Applied on the actual day of deactivation to document the removal process with screenshots.
Calendar Management: Calendar invites are sent for all deactivations. These serve as placeholders and notifications for the user access team to ensure coverage (e.g., if one team member is sick, others have a reminder to execute the removal).
Licensing and Compliance: The "Self-Audit"
Rationale for Strict Deactivations: Certain sourcing databases require Standish to perform "soft audits" or self-audits because Standish pays for the licenses directly. Failure to remove users promptly can lead to legal or financial liabilities.
Database Classification:
Standish-Managed Licenses: Pro, Virtus, Standish (NAV/CRM). Standish is legally responsible for these additions and removals.
Client-Managed Licenses: Cases where Allview or other entities bill the client directly. Standish acts only as minor users, and legal involvement is minimal.
SOC Compliance: A deactivation report must be requested from the support team (Allview) for every removal to satisfy SOC (System and Organization Controls) audit requirements.
System-Specific Deactivation Steps
ARC
Process: Navigate to the user view, select the user, and use the dropdown to select "Delete User."
Security Protocol: The system requires the word "DELETE" to be typed in all capital letters to confirm the permanent removal of the user.
Documentation: Capture a "Before" screenshot showing active access and an "After" screenshot showing "No data available" for the user search.
QuickBooks Online (QBO)
Process: Navigate to the "Team" section, locate the user, and select "Delete."
Documentation: Capture a "Before" screenshot showing the user in the team list and an "After" screenshot confirming the user is no longer found in a search.
Amalgam
Context: Amalgam is an Excel integration add-on used to run reports from QBO.
Usage Trends: Usage has declined significantly as most clients have migrated from QBO to ARC. Currently, only approximately people across the organization retain Amalgam access.
Procedure: Verify if the user is on the limited list; if so, remove access. If not, mark as "No Access" in the deactivation ticket.
Standish Database (NAV and CRM)
NAV (Microsoft Dynamics):
Navigate to the user's client access list.
Uncheck the specific clients (e.g., Balance Point) to remove their ability to post or view data within NAV.
CRM User Card:
Navigate to Settings > Users.
Locate the specific user card.
Delete the client-specific access (e.g., Balance Point).
Note: External reviewers (Allview) handle the removal of "Standish Management" roles; the internal team focuses on client-specific permissions.
CRM Contacts:
Navigate to Settings > Investor Relations > Contacts.
Identify and deactivate the contact card. If the user is associated with multiple clients (e.g., Symbiotic and Balance Point), ensure all associations are cleared.
Extranet Permissions:
Navigate to Settings > Clients > Client Extranet Permissions.
Search for the user and "Deactivate." This step must be repeated for every single client the user had access to (sometimes involving up to different clients).
Specialized Databases and Coordination
Yardi: Managed by Amy Beasley. Only authorized personnel on the onboarding team (Lisa and Amy) hold licenses to perform deactivations in Yardi. If a Yardi user is exiting, the team must coordinate with Amy.
Data Snipper: Handled externally by Kim Smith in South Africa. The internal team must notify her if a user requires removal.
Qbox: Primarily used by the former Cornerstone team (a fund admin firm in Utah acquired by Standish). Access must be checked and manually removed within the Qbox user management interface.
Jira Ticket and Review Submission
Ticket Creation: A Jira ticket is submitted to "Customer Support" under "User Access Request - Remove Individual."
Standard Verbatim for Jira: > "Hi support. Please deactivate the user per the user removal form from NAV/CRM reporting portals and investor portal. This deactivation includes your admin and impersonator accounts. Additionally, please remove any user roles/permissions from all user cards in fund accounting. And then please provide a deactivation report."
Review Chain:
Tag Chris as the primary reviewer.
Chris reviews the screenshots and documentation, then passes it to John for final approval.
The ticket must be submitted and approved on the same day as the exit to ensure compliance.
Questions & Discussion
Interactions between Lisa, Gus, and Luke:
Gus's Previous Experience: Gus shared that a large portion of his internship involved "grunt work," specifically manual sub-document extractions, bookmarking, and canceling approximately QBO files.
Luke's Safety Margin: Luke emphasized that while many tasks aren't "saving lives," terminations are critical due to the potential for retaliation or legal disputes. Documents must be postdated correctly to ensure a clean audit trail.
Technical Tip: Lisa and Luke discussed using multiple browser profiles (Chrome Main, Chrome Incognito, Edge, and Edge Incognito) to manage multiple concurrent logins for different users (e.g., Lexi, Linda) without constant session timeouts.
Miscellaneous: Lisa briefly mentioned her son's haircut and a balloon distraction during the call, adding a personal note to the session's atmosphere.