Working with a Data Validation List
At KELL, we create and share with you a data validation list. This is where you should log all issues that you discover during data validation. This is a place where you can interact with the entire KELL project team to make sure that reported issues are explained and/or resolved.
After the data walkthrough, you will receive a link to this list via email. If you do not have access to your validation list, you should ask your Project Manager (or the person who did your data map).
Logging a new issue
Enter your issue in the Task field. Try to be as descriptive as you can, so that the KELL team knows what needs to be fixed.
For example, "Phone Numbers are wrong" is not very specific. Whereas, "Mobile Phone is incorrect. It should be 555-666-7777" is very specific, and will help us to identify what went wrong.
In the Object field, you should write the name of the object where you are seeing the issue. You can identify the object in Salesforce at the top of the record you are viewing. Here's an example of a Contact:
Next, you should fill out the Record Name/Legacy ID and the Sample Link columns.
For Record Name/Legacy ID, please include both if you can. If your legacy system did not have IDs, then try to be as descriptive as you need to be in order to find that record again in the future. For instance, you could say "John Smith $50 donation 1/1/2014" if there is no Donation ID that you can refer to. This is needed because once we delete the test data and reload, the sample links you provide won't work anymore, and we want to make sure you can validate that this issue was fixed in the future.
For the sample link, simply copy and paste from your browser's address bar the exact record where you first noticed the issue. We won't address that one record alone - we'll use it to help find the problem that affects all similar records. But it's so much easier on us if we can see in Salesforce exactly what you're seeing.
For Status, you should select "Reported" Please don't select another value. Your KELL team will review all of your reported issues and make sure they are assigned to the right person.
Updating and Reviewing Previously Reported Issues
After you have logged your issues, your KELL team will review them and begin updating the smartsheet.
Type of Work Needed
The KELL team is responsible for updating this column to note what type of work needs to be done. Sometimes a reported issue is not actually a data issue, but an update to something else (like a page layout or a permission) will make that data visible to you. Other times, we might identify a training gap that we want to be sure to address in your training sessions.
You should not update this column, but it is helpful for your reference.
We ask that you try your best not to log the same issue multiple times. If you report an issue, we will fix it on ALL records, not just that one. It's also difficult to keep track of the status of an issue if it's in the smartsheet on multiple rows.
If you accidentally log an issue multiple times, the KELL team will update the Type of Work Needed to "Duplicate Issue," and the Status to "Disregard - Duplicate." In the column "Duplicate Issue Number," we will specify the original row where you can monitor the status of this issue.
Working with Statuses
|Status||Meaning||Action Required By|
|Reported by Client
||This issue has been reported by the client but not yet reviewed by KELL, or the client reviewed a fix and is reporting that the issue needs further attention
|To be fixed by KELL PM
||Flag for the PM that something needs their attention (configuration, permissions, training issue)||KELL PM|
|Reported to KELL Data Team
||KELL has confirmed that something is wrong, and has sent to the Data Team for review or clarification
||KELL Data Team|
|To be fixed by KELL Data Team
||Indicates that the data team has identified a solution and is planning to run an update||KELL Data Team|
|To be fixed by KELL Data Team in Next Load
||This will be fixed, but not until the next load. Sometimes this is necessary due to the complexity of an update.||KELL Data Team|
|To be fixed by Client
||Client is responsible for fixing this item. Used most commonly when a source data issue or something out-of-scope is going to be corrected by the Client
|To be validated by KELL
||The data team has made the update, and they are asking the PM/Data Mapper to review before the client reviews it
|To be validated by Client
||KELL has validated a fix or provided an explanation and is waiting for client review and approval.
|Client Needs Discussion
||Use this status if you need to talk to the KELL team about an issue over the phone. Please note why in the discussion bubble.||KELL PM|
|Need Client Feedback
||KELL needs more information about the issue before it can be resolved. Questions and comments can be made in the discussion bubble.
|Cover in Training
||This is a non-data question that came up, or a misunderstanding about Salesforce functionality that we want to make sure we add to a training agenda
|Approved by Client
||The issue reported in this row has been resolved and no further action is required.
|Reported and Approved by KELL
||KELL originally reported this issue (not the client). The issue reported in this row has been resolved and no further action is required.
|Disregard - See Discussion
||This is not a data issue and no action was required. Details should be noted in discussion bubble.
|Disregard - Duplicate||This is a duplicate. It will be grayed out and the original Issue Number will be noted in the "Duplicate Issue Number" column. The status of this issue will be tracked on that row.||
Avoid the temptation to put a lot of commentary and back and forth in task name itself. It's hard to format and follow a thread there. Instead, use the Discussion capability in Clickup. Click on the name of the issue to open it up for further commentary.
You can add comments here on the specific item, and you can even update a file if it helps - such as a screenshot.