As part of Wingspan's ongoing efforts to enhance workforce management capabilities, we are transitioning from the legacy Collaborator Groups and MemberClient models to the new Engagements and Contractor Engagements models. This migration aims to provide a more streamlined, flexible, and scalable approach to handling complex payer-payee relationships.

This section provides an exhaustive guide on how the old Collaborator Groups model will transition to the new Engagements model. It covers the migration process, how it affects your data, and addresses potential questions or concerns you might have.

This transition will take place from October 1st to November 1st, 2024. During this period, all users will be migrated from the legacy Collaborator Groups system to the more flexible and efficient Engagements platform. To ensure a smooth rollout, we're initiating a testing phase with a select group of users the week of Sept 23rd.

Introduction

The transition from Collaborator Groups to Engagements is designed to enhance how you manage your contingent workforce. The new Engagements model offers greater flexibility, better organization, and improved compliance management compared to the legacy Groups model.

Key Benefits of the Migration:

Streamlined Management: Simplifies workforce organization by consolidating related settings and requirements into Engagements.
Enhanced Flexibility: Allows contractors to belong to multiple Engagements with specific configurations.
Improved Compliance: Provides better tracking of contractor eligibility and compliance within each Engagement.

Overview of Changes

Collaborator Groups vs. Engagements

Collaborator Groups (Old Model): Used to organize contractors into groups for bulk actions and shared requirements. Contractors could belong to multiple groups.
Engagements (New Model): Represents a project, department, or scope of work. Each Engagement can have specific requirements and settings. Contractors have individual associations with Engagements, known as Contractor Engagements.

What's Changing:

Collaborator Groups will be migrated to Engagements.
Member Clients (associations between payers and payees) will be updated to include Engagement information.
Requirements associated with Groups will be migrated to Engagements.
Default Engagements will be created for contractors not associated with any specific Engagement.

Migration Process

The migration involves several key steps to ensure a seamless transition:

1. Migrating Collaborator Groups to Engagements

Conversion: Each Collaborator Group is converted into an Engagement.
Data Mapping: Key properties from the Group are transferred to the Engagement:
- Name: The Group's name becomes the Engagement's name.
- Description: The Group's description is assigned to the Engagement.
- Labels: Any labels from the Group are carried over to the Engagement.
- User Roles: Ownership and viewer roles are preserved in the Engagement.
Requirement Migration: Eligibility Requirements from the Group are migrated to the Engagement.

Note: Engagements created from Groups are set to Active status by default.

2. Handling Member Clients in Multiple Groups

For contractors associated with multiple Groups:

Combination Engagements: New Engagements are created to represent each unique combination of Groups a contractor belongs to.
Naming Conventions: The names of the combined Engagements are created by concatenating the names of the original Groups (e.g., "Group A & Group B").
Requirement Aggregation: Requirements from all associated Groups are consolidated into the new Engagement.
Member Client Association: Contractors are linked to these new Engagements, ensuring their multi-group associations are preserved.

3. Creating Default Engagements

For contractors not associated with any specific Group:

Default Engagement Creation: A Default Engagement is automatically created and associated with the contractor.
Purpose: Allows contractors to receive payments and fulfill requirements without additional setup.
Default Engagement Characteristics:
- Cannot be renamed or customized.
- Automatically managed by the system.
- Ensures all contractors have at least one active Engagement.

4. Deactivating Duplicate Member Clients

To maintain data integrity:

Primary Member Client Identification: The system identifies the primary Member Client record for each contractor.
Duplicate Deactivation: Non-primary Member Client records are labeled as duplicates and deactivated.
Historical Data Preservation: Deactivated records remain in the system for compliance and historical purposes.

Impact on Collaborator Groups

Groups to Engagements: All Collaborator Groups are converted into Engagements with equivalent settings and requirements.
Group IDs: The unique identifiers (IDs) of Groups become the IDs of the new Engagements.
Data Preservation: All data associated with Groups, including requirements and member associations, are preserved in the new Engagements.

Important Notes:

Archiving Groups: After migration, Collaborator Groups are effectively retired in favor of Engagements.
No Data Loss: All relevant information from Groups is retained and accessible through Engagements.

Impact on Member Clients

Engagement Association: Member Clients (contractor associations) are updated to include Engagement information.
Primary Member Client: Each contractor has a primary Member Client record associated with their default or primary Engagement.
Status Updates:
- Primary Member Client records are marked as active and linked to the appropriate Engagement.
- Duplicate or secondary Member Client records are deactivated and labeled accordingly.

Scenarios:

Contractors in Single Group: The contractor's Member Client is linked to the new Engagement derived from their Group.
Contractors in Multiple Groups: The contractor's Member Client is linked to a new Engagement representing the combination of Groups.
Contractors with No Group: The contractor receives a default Engagement, and their Member Client is linked accordingly.

Requirements Migration

Requirement Definitions: Requirements from Collaborator Groups are migrated to the corresponding Engagements.
Consolidation:
- For Engagements created from multiple Groups, requirements are aggregated.
- Duplicate requirements are identified and merged to avoid redundancies.
Contractor Compliance:
- Contractors may need to fulfill new or additional requirements based on their associated Engagements.
- The system recalculates each contractor's payment eligibility after migration.

Shared Requirements:

Some requirements may be shared across multiple Engagements. Once a contractor fulfills a shared requirement, it applies to all relevant Engagements.

Post-Migration Considerations

Review Engagements and Requirements:

Verify Engagements:
- Check the new Engagements created for accuracy in names, descriptions, and associated contractors.
Confirm Requirements:
- Review the requirements attached to each Engagement to ensure they are correct and complete.
Communicate with Contractors:
- Inform contractors of any new requirements they need to fulfill.
- Provide guidance on accessing and completing requirements within the platform.

Frequently Asked Questions

Will any of my data be lost during the migration?
No, all data from Collaborator Groups and Member Clients is preserved. The migration process ensures that all relevant information is transferred to the new Engagements model.

How are contractors associated with multiple Groups handled?
Contractors in multiple Groups are linked to new Engagements representing the combination of those Groups. This ensures that their associations and requirements are accurately reflected.

What happens to the requirements from my old Groups?
Requirements are migrated to the corresponding Engagements. For contractors associated with multiple Groups, the requirements are consolidated in the new Engagements.

How are duplicate Member Clients handled?
Duplicate (non-primary) Member Client records are deactivated and labeled as duplicates. The primary Member Client remains active and is associated with the appropriate Engagement.

Can I still create new Engagements after the migration?
Absolutely. The migration sets the foundation with Engagements based on your existing Groups, but you can create new Engagements at any time to suit your organizational needs.

What if a contractor doesn't fulfill the new requirements after migration?
Contractors who have not fulfilled all the requirements of their Engagement will have a Not Eligible payment status. They will need to complete the outstanding requirements to become Eligible for payments.

How does the migration affect payment processing?
Payment processing is now managed through Contractor Engagements within each Engagement. Contractors must have an Active status and be Payment Eligible within an Engagement to receive payments.

Are there any changes to how I manage contractor compliance?
Yes, compliance is now managed at the Engagement level. Requirements are set per Engagement, and contractor compliance is tracked within their Contractor Engagements.

Can I customize the default Engagements?
Default Engagements have limited customization options. They cannot be renamed, and requirements cannot be added. They are designed to facilitate immediate transactions and basic interactions.