Departed Employee
Data Archaeology

Executive Summary

Twenty employee records are inactive in this account. The survey found that business data is in materially sound condition — no customer, case, task, or open approval depends on a departed employee — while automation ownership is significantly orphaned: 213 active saved searches, 81 scripts, and approximately 100 live script deployments remain owned by former staff, including four scheduled jobs that continue to execute.

Scope & Methodology

Definition of "Departed"

An employee record was classified as departed where employee.isinactive = 'T' or releasedate was populated. In practice all 20 qualifying records carried the inactive flag and none carried a release date (see Section 11, Assumption A1).

Survey Domains

Nine domains were examined: saved searches, script records, script deployments, workflows, role assignments, approval chains (four approver fields plus pending transaction approvals), customer sales-rep relationships, sales team memberships, and CRM activity records (cases, tasks, events, phone calls). File-cabinet ownership and CSV import maps were attempted but are not queryable in this account (Appendix B).

Execution

The census was performed in the primary session; three read-only research agents were then dispatched in parallel to survey automation assets, roles and approvals, and business-data references respectively. All agent findings bearing on the findings register were re-verified or cross-checked in the primary session. Every query executed appears verbatim in Appendix A. No record was created, modified, or deleted during this engagement.

Departed Employee Census

Twenty inactive employee records. Seven own at least one asset; the remaining thirteen own nothing discoverable and require no action.

† Sole remaining holder of role 1659 (SS RT PRM – A/P Analyst); see Finding F-04. "Login: Revoked" reflects giveaccess = 'F' on all twenty records.

Findings Register

Automation Assets

F-01 — Scheduled deployments still executing (owner: Ryan Rote, id 1252)

Four additional deployments owned by departed staff are deployed but not currently scheduled (customdeploy_snav_copysublogo, customdeploy_de_dept_hotfix_ss, and script ids 457, 460, 700, 701).

Script and deployment footprint by departed owner

Saved searches (213 total; all active, all public)

Roles & Access

Every role held by a departed employee was tested for surviving active holders. One role is orphaned.

All twenty departed records carry giveaccess = 'F': no departed employee can log in. Fourteen of the twenty formerly held the Administrator role — an observation about historical provisioning breadth that management may wish to note for its joiner-mover-leaver policy, though it presents no current exposure.

Approval Chains

Three tests were applied; all returned zero exceptions.

1. Organizational references. No active employee names a departed employee as supervisor, approver, purchaseorderapprover, or timeapprover. (0 rows)
2. Pending approvals. No transaction of any type carries a departed employee as nextapprover. Nothing is stuck. (0 rows)
3. Workflow ownership. No workflow record is owned by a departed employee. (0 rows)

Business-Data References

The 48 phone-call records (internal ids 14–61) are all owned by Jenny Lunsford03 (id 6) and all remain in SCHEDULED status. They are demonstration-era CRM artifacts; the recommended disposition is bulk reassignment or completion/cancellation.

Domains Verified Clean

For completeness and auditability, the following were affirmatively verified as carrying zero departed-employee dependencies, each by direct query (Appendix A):

• Customer sales-rep assignments, sales team memberships, and support case assignments
• Transaction employee attributions and pending approval queues (nextapprover)
• Supervisor, expense approver, purchase-order approver, and time approver hierarchies
• Workflow ownership
• Login capability (giveaccess = 'F' on all twenty records)

Remediation Plan

Assumptions & Limitations

1. A1 — Departure definition. "Departed" was operationalized as isinactive = 'T'. No record carried a releasedate, and several carry hire dates postdating this report (a known artifact of demonstration data). If any of the twenty were inactivated for reasons other than departure, their findings transfer unchanged — the assets are orphaned either way.
2. A2 — Bundle provenance is inferred. The script table does not expose bundle lineage in this account; SCM / Atlas / Subsidiary Navigator attribution rests on scriptid prefixes and naming conventions. Treat the bundle/hand-built split as high-confidence but not record-proven.
3. A3 — File-cabinet ownership unauditable. file.owner is not exposed to SuiteQL here; files owned by departed employees could not be enumerated. A UI-based audit (Documents → File Cabinet, filter by owner) would close this gap.
4. A4 — CSV import maps and search schedules undiscoverable. No SuiteQL table for import maps or saved-search email schedules exists in this account. Scheduled-search emails addressed to departed staff, if any, were not visible to this survey.
5. A5 — Role assignments read from a derived column. employee.rolesforsearch is a derived multiselect; it was enumerated in full and matched in-session rather than filtered server-side (see Appendix B). Counts were spot-verified against known holders.
6. A6 — Point-in-time. All figures reflect account state as of August 24, 2026. The queries in Appendix A are deterministic and re-executable for refresh.

Queries Executed

All queries are SuiteQL, executed read-only under the reporting user's Administrator role. Ellipsized id lists denote the full set of twenty departed employee ids: 5, 6, 10, 1220, 1221, 1223, 1224, 1225, 1248, 1249, 1251, 1252, 1357, 1358, 1359, 2086, 2107, 3870, 3872, 3873.

SELECT id, entityid, firstname, lastname, title, email, isinactive, releasedate,
       hiredate, issalesrep, issupportrep, giveaccess, rolesforsearch, supervisor,
       approver, purchaseorderapprover, timeapprover, subsidiary, department, location
FROM employee
WHERE isinactive = 'T' OR releasedate IS NOT NULL
ORDER BY lastname

SELECT s.id, s.scriptid, s.name, s.scripttype, s.owner, s.isinactive
FROM script s
WHERE s.owner IN (5, 6, 10, ..., 3873)

SELECT ss.id, ss.scriptid, ss.name, ss.searchtype, ss.owner,
       ss.isinactive, ss.ispublic, ss.isshared
FROM savedsearch ss
WHERE ss.owner IN (5, 6, 10, ..., 3873)
ORDER BY ss.owner, ss.id

SELECT s.owner, s.id AS script_id, s.name AS script_name, s.scripttype,
       d.id AS deploy_id, d.scriptid AS deploy_scriptid, d.status, d.isdeployed
FROM scriptdeployment d
JOIN script s ON d.script = s.id
WHERE s.owner IN (5, 6, 10, ..., 3873)
  AND d.isdeployed = 'T'
  AND s.scripttype IN ('SCHEDULED', 'MAPREDUCE')
ORDER BY s.owner, s.id

SELECT s.owner, s.scripttype, COUNT(*) AS deployed_cnt
FROM scriptdeployment d
JOIN script s ON d.script = s.id
WHERE s.owner IN (5, 6, 10, ..., 3873) AND d.isdeployed = 'T'
GROUP BY s.owner, s.scripttype
ORDER BY s.owner

SELECT w.internalid, w.scriptid, w.name, w.owner, w.isinactive, w.releasestatus
FROM workflow w
WHERE w.owner IN (5, 6, 10, ..., 3873)

SELECT id, name, scriptid, isinactive, centertype
FROM role
WHERE id IN (3, 15, 1659, 1660, 1662, 1663, 1664)

SELECT id, entityid, isinactive, rolesforsearch, giveaccess
FROM employee
WHERE isinactive = 'F' AND rolesforsearch IS NOT NULL

SELECT id, entityid, isinactive, supervisor, approver,
       purchaseorderapprover, timeapprover
FROM employee
WHERE supervisor IN (5, 6, 10, ..., 3873)
   OR approver IN (5, 6, 10, ..., 3873)
   OR purchaseorderapprover IN (5, 6, 10, ..., 3873)
   OR timeapprover IN (5, 6, 10, ..., 3873)

SELECT type, COUNT(*) AS cnt
FROM transaction
WHERE nextapprover IN (5, 6, 10, ..., 3873)
GROUP BY type

SELECT id, entityid, companyname, salesrep
FROM customer
WHERE salesrep IN (5, 6, 10, ..., 3873)

SELECT cst.customer, c.entityid, c.companyname, cst.employee,
       cst.salesrole, cst.isprimary, cst.contribution
FROM customersalesteam cst
JOIN customer c ON cst.customer = c.id
WHERE cst.employee IN (5, 6, 10, ..., 3873)

SELECT id, casenumber, title, assigned, status, BUILTIN.DF(status) AS status_name
FROM supportcase
WHERE assigned IN (5, 6, 10, ..., 3873)

SELECT type, COUNT(*) AS cnt
FROM transaction
WHERE employee IN (5, 6, 10, ..., 3873)
GROUP BY type

SELECT id, title, assigned, status FROM task
WHERE assigned IN (5, 6, 10, ..., 3873);

SELECT id, title, owner, status FROM task
WHERE owner IN (5, 6, 10, ..., 3873);

SELECT id, title, status, owner, organizer, startdate FROM calendarevent
WHERE owner IN (5, 6, 10, ..., 3873) OR organizer IN (5, 6, 10, ..., 3873);

SELECT id, title, status, owner, assigned, startdate FROM phonecall
WHERE owner IN (5, 6, 10, ..., 3873) OR assigned IN (5, 6, 10, ..., 3873)

Schema Quirks Discovered

Recorded so that future re-runs of this survey do not repeat the same discovery cost.

1. B.1 — file.owner is NOT_EXPOSED to SuiteQL in this account; file-cabinet ownership cannot be audited by query.
2. B.2 — Nonexistent tables: usersavedsearch, csvimport, csvimportmap, importmap, scheduledsearch, and salesteam all return "Invalid search type." The sales-team mapping lives in customersalesteam.
3. B.3 — scriptdeployment carries no owner column; ownership is resolved only through the join to script.owner.
4. B.4 — employee.rolesforsearch is not reliably filterable server-side. A LIKE predicate against it returned zero rows despite known matches; the derived multiselect must be enumerated and matched client-side. This survey did so and spot-verified against known role holders.
5. B.5 — transaction.salesrep and transactionline.salesrep are not exposed here; sales-rep exposure was assessed via customer.salesrep and customersalesteam instead.
6. B.6 — supportcase.escalateto is unfilterable ("Invalid or unsupported search"); escalation chains could not be tested and are a residual blind spot alongside A3/A4.