Claire and Eli clicked around on production and identified several "duplicate vendor" use cases that we'd likely need to consider outside of the Vendor Deduplication tool:
Same Vendor, Different Office It looks like the most common "duplicate vendors" are vendor records that are repeated across offices. Like this:
Right now, vendors can only belong to one office. A few options we have here are:
- Do nothing and allow many offices to have the same vendor
- "Link" the vendors so that updates to one affect both
- Remove the direct Vendor belongs_to Office relationship, and implement a many-to-many there instead. So one Vendor record could be accessed by teams in multiple offices (this would better model the real world, which makes it probably the right call in the long run)
Same Vendor, Different Role Similar to above, should we allow vendors to have multiple roles? Or, would we rather leave these as unique records, so in the future, agents can "review" their experience with Jonathan Warrington as a pest inspector separately from their experience with him as a home inspector.
Same Vendor, Not all values match
This is where a vendor deduplication tool would be most valuable, as this should obviously be one person. We're thinking the "Vendor Merge" tool would let you pick which version you'd keep for the final record.
Our vision for the UI here is 2 new pages. An index page that lists all of the possible duplicates we can programmatically find. and a "resolve" page where you see the multiple records side by side and you get to select which values to keep in the condensed resource.
Next Steps
- Discuss open questions above on our 3/19 call
- Share sketch of UI on our 3/19 call