Introducing the ignore objects function

Merge customers can now specify what end-user data is stored in Merge’s servers with the ‘ignore’ object request for any HR and payroll or ATS object.

In this post, we'll walk through our product decision to use 'ignore,' and walk you through some use cases for when to use this feature.

Why ‘Ignore’ and Not Something Permanent like ‘Delete’? 

Merge is not the source of truth for our customer’s data. Part of the function of a Unified API is to poll and normalize data from various vendors in the HR and payroll, recruiting, and accounting spaces and store it on our customer’s behalf.

Because Merge pulls data regularly, if we were to delete an Employee's data in our database at 1 pm we'd end up pulling the deleted Employee's data again at 4 pm. When thinking about how we want to account for these issues and best allow our customers to comply with security or data storage concerns, the idea of simple 'deleting' data doesn't make sense.

By using ‘ignore,’ we set the ignored model and any related models to a ‘null’ value in our servers. This means that even if the data is sent from a third-party application to Merge,  Merge’s servers know to not bother with the ignored model and so won’t save that data. This ensures you remain compliant with whatever boundaries your users have set.  

More importantly, ‘ignore’ scales as we add new models and features – meaning that you can trust Merge to help you stay in compliance for the long run. 

Use Cases - When You’d Use the Ignore Objects Feature

Let’s run through some examples of when you’d use the ignore feature. Don’t see your use case below? Our team is always happy to chat on Intercom and answer your question!

Problem: For privacy reasons, a recruiting candidate doesn’t want their data stored by your system. 

Solution with Merge: Send a POST request to Merge for /candidates/ignore/{model_id} where {model_id} is equal to the specific candidate’s id. On every subsequent pull of data between Merge and the ATS that the candidate is stored in, Merge will ignore the specified candidate's data and all subsequent fields relating to the candidate. 

Problem: For the HR tasks your platform accomplishes, it’s unnecessary to store information on consultants or executives employed at a customer’s company. 

Solution with Merge: Send one POST request to /employees/ignore/{model_id} per employee, where model_id is equal to the id of an employee belonging to a “team” object that represents “consultant” or “executive” in your system.

Problem: One of your customers no longer wants any of their data stored by Merge, and doesn’t want to be connected through your service.

Solution with Merge: Here we would use the POST /delete-account function, which deletes an entire linked account. Even though we’re deleting data, we don’t have to worry about subsequent data being stored through polling: Merge won’t even consider the (now deleted) Linked Account as something poll-able.

Problem: Because of a rise in popularity, let’s say Merge adds a new field called “favorite_food” to our common Candidate data object. You’ve previously asked Merge to ‘ignore’ several Candidates, but because the “favorite_food” field wasn’t present in your initial request, you’re worried Merge will ignore your ignore and pull the “favorite_food” field for these Candidates! Do you need to submit another ‘ignore’ request to prevent this from happening?

Solution with Merge: Nope! This is not a problem. Our code is smart enough to see that the candidate was ignored and know that all future related objects to that candidate are ignored. We know that having to write repeated requests on your own takes time and engineering resources that can be better spent writing features you care about!

If you’ve been having difficulty managing customer privacy through integrations, or want to explore more options to remain compliant with user requests, then we’d love to chat! 

Schedule a demo today or sign up for free and start experimenting with Merge today!