Definition

The Remove user from workspace action allows you to programmatically remove specific users from your current Zenphi workspace. This ensures that user access is managed efficiently, particularly during offboarding processes or when cleaning up inactive accounts.

Key capabilities include:

• Removing multiple users simultaneously by providing their email addresses.
• Automatically transferring ownership of the deleted users’ Flows and Shared Settings to a designated new owner.
• Preventing the accidental removal of the Workspace Owner or Administrators to maintain system integrity.

This action is essential for automating user lifecycle management, ensuring that when a user is removed, their assets are safely reassigned and access is immediately revoked.

Important Notes

• This action is not available by default in your workspace. If you want to use it, please reach out to our support team and we will enable it for you.
• Security Requirement: Only users with the Workspace Admin role have the permission to save and publish a flow containing this action.
• The Workspace Owner cannot be removed via this action. If you need to remove or change the Workspace Owner, please reach out to our support team.
• Administrators cannot be removed using this action; they must be demoted or removed manually.

Inputs

1. User Emails:

• Purpose: This field identifies exactly which users should be removed from the workspace.
• Practical Guidance: You can provide the email addresses in two ways. For a static value, simply type the email addresses into the field, separating multiple emails with a comma (e.g., john.doe@company.com, jane.smith@company.com). For a dynamic value, use the token picker to map an email address or a text string from a previous step (such as a form submission or a database query).
• Use Case Context: You would use this field to map an employee email token from an HR system trigger to automatically remove that employee when they leave the company.

2. New Owner Email:

• Purpose: This field specifies who will inherit the Flows and Shared Settings previously owned by the users being removed.
• Practical Guidance: Enter the valid email address of the user who should take over ownership. This can be a specific manager’s email typed as a static value, or a dynamic value selected via the token picker. This step is critical to prevent orphaned flows (automations that stop working because their owner no longer exists).
• Use Case Context: You would use this field to assign the IT manager’s email so that all business-critical automations created by the departing user continue to run without interruption.

Outputs

1. Deleted User Emails:

• Data Description: A list of text strings representing the email addresses of the users who were successfully removed from the workspace.
• Workflow Utility: This output is useful for verification and logging. You can pass this list into a Foreach loop to send a confirmation notification for each removed user, or update a record in your HR database to confirm that the offboarding process in Zenphi is complete.

Example Use Cases

1. Automate Employee Offboarding: Automatically remove departing employees from the Zenphi workspace as soon as their termination is processed in the HR system.

2. Manage Contractor Access: Delete external contractor accounts and revoke access immediately upon the expiration of their contract date.

3. Preserve Business Continuity: Ensure that Flows and Shared Settings owned by a removed user are automatically transferred to a manager or IT admin to prevent service interruptions.

4. Optimize License Usage: Periodically clean up inactive user accounts to free up licenses for new team members without losing the assets they created.

5. Secure Access Revocation: Instantly remove user access during security incidents while safely retaining ownership of their automation assets.

Example

Scenario: Your HR team uses a Google Form to initiate the offboarding process for employees. When an employee leaves the company, their access to the Zenphi workspace must be revoked immediately to maintain security. However, it is critical that any automated Flows or connections they created are not lost; they must be transferred to their reporting manager to ensure business continuity.

Steps to Implement:

1. Trigger Selection: Select the Google Form trigger. Configure it to watch for submissions from your “Employee Offboarding Request” form, which captures the employee email and the manager email.

2. Configure the Remove user from workspace Action: Add the Remove user from workspace action after the trigger to process the removal.

• User Emails: Click the token picker and select the employee email field from the Google Form trigger outputs.
• New Owner Email: Click the token picker and select the manager email field from the Google Form trigger outputs. This ensures that all Flows owned by the departing employee are transferred to this manager.

Outcome: Upon form submission, the specified employee is immediately removed from the Zenphi workspace. Simultaneously, ownership of all their existing Flows and Shared Settings is seamlessly transferred to the designated manager. This prevents orphaned automations and ensures the manager has full control over the previous employee’s work without manual intervention.

Best Practices

1. Designate a Service Account: Consider using a generic IT service account (e.g., automation@company.com) as the new owner email instead of a specific individual to ensure long-term continuity if the manager also leaves.

2. Audit Removed Users: Always map the deleted user emails output to a logging action (like adding a row to a Google Sheet) to maintain a compliance trail of who was removed and when.

3. Verify User Roles: Remember that this action cannot remove the Workspace Owner or Administrators; ensure your workflow logic accounts for this limitation or handles these high-level users manually.

4. Validate Email Formats: Ensure that the email addresses provided in the user emails field are valid and correctly formatted, especially when dynamically mapping from external systems, to prevent action failure.