User Deactivation

Deactivating a user will disable their Platform account. Before deactivating a user, review the sections below on consequences, credential handling, and object transfer, since some cleanup steps need to happen before the account is deactivated.

Requesting an Object Inventory

Civis Support (support@civisanalytics.com) can provide a list of the following objects for a given user:

• Scheduled Workflows
• Scheduled Jobs, including those scheduled by a Workflow
• Credentials
• Script Templates and their associated Backing Scripts

Consequences of Deactivating a User

Deactivating a user that is the owner or runner of production Jobs or Workflows can cause those workloads to fail or become unstable. When a user is deactivated, the following actions happen automatically:

• The user account cannot be logged into
• Other users cannot assume the role of the deactivated user
• All jobs the user is the runner of or owner of will be unscheduled
• All workflows the user is the owner of will be unscheduled
• The user's Services are shut down
• The user is removed from the organization
• The user's database account is expired for Civis-managed Redshift and Postgres databases (see the Redshift and Postgres account docs for additional detail — links still needed here)
• Objects owned by a deactivated user can no longer be transferred

Because that last point means transfers become impossible after deactivation, object and credential transfers should happen before deactivation whenever possible.

Users Running Code Integrated from GitHub

If a user's linked GitHub account is deactivated or loses access to organizational repositories, and that user is the runner of a Template Backing Script that pulls code from GitHub, all runs of child scripts created from that Template will fail with GitHub authentication errors. This can happen as soon as the user loses GitHub access, even before the Civis user itself is deactivated.

Templates and their children will keep running as long as the deactivated user's GitHub credential stays valid, even after the Civis user has been deactivated. This is because all child scripts created from a Template use the Civis GitHub Credential of the Backing Script's runner to pull code from GitHub. This lets users without GitHub read access run the Template, but it creates a dependency on the runner's GitHub account staying valid.

Credentials That Should Not Be Transferred

GitHub Credential

To identify a user's GitHub Credential in the list provided by Civis Support:

1. Find the credential named "github." Not every user will have one. If there's no credential named "github" in the list, the user did not have a GitHub Credential.
2. Assume the user's role, navigate to the credentials index, and find the credential with the matching ID. You can optionally use the Type filter to show only GitHub-type credentials.
3. Confirm the Type column for that credential reads "Github: Github API Connection."

The Civis GitHub integration links each Civis user to exactly one GitHub account, managed through the OAuth GitHub Credential creation flow. If a user ends up with access to more than one GitHub Credential, code pull/checkout will fail. For this reason, GitHub Credentials should not be transferred when deactivating a user. If a new user needs access to the underlying GitHub assets, grant them access directly in GitHub and have them create their own GitHub Credential through the standard flow.

Default Database Credential(s)

To identify a user's Default Database Credential(s):

1. Find the credential(s) with the same name as the Civis user (for example, a robot user named "reportingrobot" would typically have a matching database credential named "reportingrobot").
2. Assume the user's role, navigate to the credentials index, and find the credential with the matching ID. You can optionally use the Type filter to show only Database-type credentials.
3. Look for the credential tagged "Default" in the Type column where the Owner matches the username being deactivated.

Sharing or transferring these credentials is unlikely to cause errors, but best practice is to transfer the user's database assets (see below) so their database credential becomes unnecessary to transfer, since the deactivated user will no longer own any schemas or tables. For more information, see the Default Credential documentation.

Transferring Civis Objects

Most Civis objects (Workflows, Credentials, Reports, Scripts) can be transferred through the GUI using the Transfer Ownership action, found under the standard action menu (the three dots in the upper right of the object's page). A small number of object types, such as Templates and Database Syncs, can only be transferred via the Civis API. Civis Support can assist with API-only transfers where needed.

If the user has already been deactivated, they can be temporarily marked as a robot and reactivated to facilitate transfers. This topic is covered in greater detail on the Transfer Ownership page.

Transfer Requirements

To successfully transfer an object to a new owner, the user making the transfer must have all of the following:

1. Be the current object owner, or have manage permission on the current object owner
2. Manage permission on the object
3. Manage permission on the target user

Transferring Database Objects

In addition to transferring Civis objects, transfer database objects owned by the departing user. Failure to transfer database objects is less likely to cause processes to fail than failure to transfer Civis objects, but it's still an important part of a clean handoff.

Tables and schemas can be transferred directly. Views must be rebuilt under the new owner.

Database Object Ownership and Transfer Query

Run the following query to list the database objects owned by a user and generate the SQL statements to transfer those objects to another user. Replace the source_user and target_user values in the transfer_users CTE before running it. A placeholder target username can be used on a first pass if the target user hasn't been determined yet.

WITH
transfer_users AS (
  SELECT
    <source username> AS source_user,
    <target username> AS target_user
),
source_user_database_objects AS (
  SELECT
    'SCHEMA' AS object_type,
    NULL AS schema_name,
    nspname AS object_name,
    u.usename AS owner
  FROM
    pg_namespace n
    JOIN pg_user u ON n.nspowner = u.usesysid
  WHERE
    u.usename = (SELECT source_user FROM transfer_users)
  UNION ALL
  SELECT
    'TABLE' AS object_type,
    schemaname AS schema_name,
    tablename AS object_name,
    tableowner AS owner
  FROM
    pg_tables
  WHERE
    tableowner = (SELECT source_user FROM transfer_users)
  UNION ALL
  SELECT
    'VIEW' AS object_type,
    schemaname AS schema_name,
    viewname AS object_name,
    viewowner AS owner
  FROM
    pg_views
  WHERE
    viewowner = (SELECT source_user FROM transfer_users)
  ORDER BY
    object_type,
    schema_name,
    object_name
)
SELECT
  sudo.*,
  CASE
    WHEN sudo.object_type = 'TABLE' THEN 'ALTER TABLE ' || sudo.schema_name || '.' || sudo.object_name || ' OWNER TO ' || (SELECT target_user FROM transfer_users) || ';'
    WHEN sudo.object_type = 'VIEW' THEN 'ALTER VIEW ' || sudo.schema_name || '.' || sudo.object_name || ' OWNER TO ' || (SELECT target_user FROM transfer_users) || ';'
    WHEN sudo.object_type = 'SCHEMA' THEN 'ALTER SCHEMA ' || sudo.object_name || ' OWNER TO ' || (SELECT target_user FROM transfer_users) || ';'
    ELSE NULL
  END AS alter_statement
FROM
  source_user_database_objects sudo;

Table Transfer Required Redshift Privileges

One of the following is required to alter a table's ownership:

• Superuser
• User with the ALTER TABLE privilege
• Table owner with the USAGE privilege on the schema

Schema Transfer Required Redshift Privileges

One of the following is required to alter a schema's ownership:

• Superuser
• User with the ALTER SCHEMA privilege
• Schema owner

Deactivation Process

Deactivations may be proactive or reactive, depending on the circumstances of the individual leaving.

• Proactive: the account is deactivated before the person leaves, and they're involved in the transition, providing guidance on or making the object transfers themselves.
• Reactive: the person has already left the organization before the account is deactivated, and they are not involved in the transfer.

Proactive Deactivation Process

1. The departing user (or an admin on their behalf) submits a ticket to support@civisanalytics.com requesting a list of the user's scheduled Jobs/Workflows, Credentials, and Templates.
2. The user reviews the object list and identifies which items should be unscheduled or archived, and which should be transferred, along with the target user for each. Ideally, all items are transferred to a robot.
3. A database superuser runs the Database Object Ownership and Transfer Query. A placeholder target username can be used here if needed, then the query re-run once the target user is confirmed.
4. The user reviews the database object list and decides whether each object should be dropped or transferred, and to whom. Ideally, all items are transferred to a robot.
5. A superuser executes the ownership statements generated by the query.
6. If the user has sufficient permissions on the target user, they make the Civis object transfers themselves. If not, an admin with Superadmin Mode access makes the transfers. Note that Superadmin Mode does not cover Credentials: for those, an admin needs to assume the departing user's role, share the credential with their own account, then transfer it from their own account.
7. Once all transfers are complete, the user is deactivated in Civis and GitHub.

Reactive Deactivation Process

1. An admin changes the user to a robot account. This preserves the user's scheduled work, allows role assumption, and prevents anyone from logging into the account directly.
2. An admin submits a ticket to support@civisanalytics.com requesting a list of the user's scheduled Jobs/Workflows, Credentials, and Templates.
3. An admin reviews the object list and identifies which items should be unscheduled or archived, and which should be transferred, along with the target user for each. Ideally, all items are transferred to a robot.
4. A database superuser runs the Database Object Ownership and Transfer Query. A placeholder target username can be used here if needed, then the query re-run once the target user is confirmed.
5. An admin reviews the database object list and decides whether each object should be dropped or transferred, and to whom. Ideally, all items are transferred to a robot.
6. A superuser executes the ownership statements generated by the query.
7. An admin with Superadmin Mode access makes the Civis object transfers. Superadmin Mode does not cover Credentials: an admin may need to assume the current user's role, share the credential with their own account, then transfer it from their own account.
8. Once all transfers are complete, the user is deactivated in Civis and GitHub.

How to Deactivate a User

1. Navigate to the user's standard action menu (the three dots) and select Deactivate User.
2. In the confirmation modal, select Deactivate.