Vendor Name Changes

 

Prepare

  1. Set a cutoff date to make all changes (the end of a month)
  • It is best to pick a date in the future.
  • Execute changes at the end of the last business day of the month.
  • If the cutoff date has already passed, you will need to:
    • Update sources on all old leads in leads_raw - data back to the cutoff date
    • Set those rows to reprocess_file=true

Execute

The following steps need to be taken to ensure a smooth transition when vendors change names.
On the cutoff date, execute all changes:

1. Postgres Tables

  1. Source Aliases
    1. Check claripedia.source_aliases table to see if the new vendor name already exists as an alias.
      1. If the new name exists in source_aliases, remove it.  It needs to be in the sources table instead.
  2. Sources
    1. Check claripedia.sources table to see if the new vendor name already exists.
      1. If new name already exists, verify that the channel is the same as the previous source (if not, change it so it is)
      2. If the new name does not exist, add it to the table.  channel needs to be the same as the old source's channel.
  3. Source Classification
         In the third_party_data.source_classification table:
    1. Check source classification for the old vendor
    2. Check source classification for the new vendor
      • If it already exists, target_channel needs to be same as the old vendor's target_channel 
      • If not, add it, and make the target_channel the same as the old vendor's target_channel 
  4. Lead Data Suppliers
         In the claripedia.lead_data_suppliers table:
    1. Do not delete the old lead data supplier
    2. Add a new lead data supplier.
      1. These fields will be different:
        1. preprocessing_key
        2. display_name
        3. source   (if old source was null, use null on the new source)
      2. The new lead data supplier entry should have the same settings/flags as the old one:
        1. raw_lead_type
        2. channel
        3. get_date_from_filename
        4. get_campaign_from_filename
  5. Leads Schema Mapping Custom Headers
         In the claripedia.leads_schema_mapping_custom_headers table:
    1. Do not delete the old mappings for the old preprocessing_key (previous vendor name)
    2. Make a copy of all mappings under the new preprocessing_key (new vendor name)

2. Dropbox Folders

  1. Rename all Insyncing Dropbox leads subfolders (under property folders) - rename to the new preprocessing_key
    1. Do NOT update Data Archive folders.  We want to preserve the history of files as they were loaded originally.
  2. Update all Dropbox IDD links on Monday boards:
    1. SA+TVA Ops Monthly Tasks
    2. MTSA Source Reports Properties
       

3. Engineering Changes:

  1.  APIs - Request updates to:
    1. third_party_data.prod_third_party_vendors - update vendor_name and display_name
    2. third_party_data.prod_third_party_data_config table - update vendor_name on all existing entries (Ops can do this but only after Engineering updates the third_party_vendors table)
    3. DMUI - 3rd Party entry page
      1. Display name on page
      2. vendor_name that the entry is mapped to in third_party_data_config table
    4. Github 
      1. DAG names
      2. Code - update the lead data supplier that the leads are being mapped to (and source if necessary)
      3. Code - update any other references to the vendor name
    5. Airflow
      1. DAG names
      2. Code - update the name of the Github DAGs that are being called
    6. Jobs/Jumphost server Log file names
  2. Scraper - Request updates to:
    1. Scraper bucket filenames
    2. Lead Data Supplier used for ETL ingestion of leads
    3. Rename all existing customers in WALLE_CONFIG_DATA
    4. Rename all existing customers in WALLE_CONFIG_INIT

4. Monday boards

  1. Vendor Details board entry
  2. Monday vendor email fire text (automations on OB Tasks and Monthly Tasks)
  3. Rocketlane vendor email fire text and task names  (coordinate with CS Specialist)
  4. Vendor dropdowns on OB Tasks and Monthly Tasks
  5. OB Tasks - rename all existing tasks
  6. Monthly Tasks - rename all existing tasks

 

QA

After changes are made, QA the data for all clients.

  1. Leads QA 2 - ensure leads are appearing under the new vendor name
  2. Leads Attribution QA - ensure the new lead data supplier is receiving attribution
  3. DMUI Attribution - if the vendor has a hardcoded source, check DMUI attribution to ensure new source is attributing.  Check a random sampling of about 3-5 properties.

 



Can't find what you're looking for?

Our team is here to help.

Contact Support