FAQs

The “Confirmed - By Dropping Secondary Info” status addresses are always hard to deal with. What it means is that an apartment, or suite, or some other secondary number was given on the street line, and it isn't recognized. Now, that can happen for many reasons. First, it might be wrong, or a typo. Second, it might be correct, but unregistered. The only way to really know if it is valid is to ask the person. But even then, IF it is correct according to the person, the mail carrier might not deliver it. Perhaps the regular carrier knows that "Apt A" is a certain door, but on a particular day a different mail carrier might not know that, since it isn't marked.

How to treat these addresses is a decision each business needs to make on their own. But one thing that should be done, is to follow up and make sure it isn't a typo.

The reason is is failing is because the import is running in batch mode to create the records. Quite simply, Salesforce refuses to start a batch process FROM a batch process, and since our app runs in batch code (it has to) it basically means that it cannot be called from a batch process.

So, we recommend setting up a job that runs once every night or perhaps more than once per day, to verify these records that are imported.

If you purchase your Smarty.com lookups through us (to get the discount on the app), then our process is that we check stats once per month and if you are getting close to your annual number, then you have the choice to either upgrade to a bigger package, or else wait until the end of your license term and pay an overage at the same rate as your existing package. The best choice depends on how far over you will be going. If you purchase your Smarty.com lookups directly from Smarty.com, you can set up an automated renewal, or else the lookups will stop working when you reach the limit. (This does not happen if you purchase with us.)

This is happening because of new fields that Salesforce is adding to the available ones with each release. Sometimes these fields are not fully available to all clients, and errors such as these are thrown. An upgrade to the latest version of our app should fix the issue.

First, make sure you have created a section on the object layout called "Address Information" (you can change this term in the Object Setup in the Configure page). Second, if the error persists: Go to Setup -> Search Tabs -> In the "Custom Object Tabs" Click on New -> Object: √ Layouts (choose the address verification Layout), for Select a Tab Style, Next-> Next-> Save. Now, go to App Launcher -> Search Layout (√ Layouts) and -> Delete all the records that are available. When you launch the Autocomplete page again, it should refresh these records. You can now delete the tab you created.

Go to Configure -> Data Mapping and edit the object you are trying to run a batch job on. If it does not exist, click "Add Support Object". Once you are in the Object, click in the ‘Active Job Id Field’ and paste the API name of a Text field (at least 18 characters long) which currently exists in the object. Note: If this value is left blank, no batch jobs can be run on the object.

The Deputy object is temporary object that is used during the verification process. Our batch jobs do the work in 3 steps. First, the address from the source record is copied to a new Deputy record. Then, the deputy records are verified. By verifying these records instead of the source records, we avoid performance degradation from flows and triggers, as well as record locks, validation rules, etc., that slow down or break a batch job. The final step is to copy the verified data into the original source records. After that is complete, the Deputy records are marked as completed, and are deleted with a scheduled Apex job. You can read how to set up the scheduled Apex job in the implementation guide.

Here are the fields to update in order to ensure that Address Verification sees the address and completely verified, and treats it just as if it was verified through the standard processes:

Verified checkbox set to TRUE

Last Verified date/time field set to today

Return Code field set to "Confirmed"

Footnotes field set to "Manually Set to Verified" (or similar)

Smarty.com, does not support the NCOA database. They used to, but did not find it that valuable for their clients.

You can read more about it here:

https://www.smarty.com/docs/will-your-service-tell-me-if-somebody-lives-at-an-address

https://www.smarty.com/articles/is-move-updatencoa-required

We transfer absolutely no PII information in the calls to 3rd party database hosts (Smarty.com or other APIs for email/phone, etc.) and don't even include a record Id that could trace the call back to a particular record in your database. That information is tracked soley inside of your Salesforce system, and we have no access to it in any way. We stay out of the handling of PII data completely so that we don't have to be involved in any security discussions.

Our application sits completely installed in your own Salesforce instance. When you install it, you give it the right to access your fields and objects, but there is no outside party or system that can access the data. Everything is self initiated on your end. You send anonymous data to the various REST APIs (Smarty.com for physical addresses, etc.), and they return the corrected data back to your Salesforce instance. This data contains nothing personally identifiable for the REST API to connect to a person. So it is fully PII compliant with all FTC standards.

Now, Smarty.com which houses the address data, and replies to our API calls, also takes HIPPA (and PII in general) very seriously. Read more about it here:

https://www.smarty.com/docs/hipaa

https://www.smarty.com/articles/personally-identifiable-information

In case you want absolutely no trace of your data requests, Smarty.com does offer an "Enhanced Data Privacy" which is quite expensive, but would basically not keep any logs of your requests or their own replies. They describe it thus:

"Enhanced Data Privacy" also referred to as "Incognito mode" is an optional Upgrade feature that Enterprise Clients may elect to purchase which prevents Client Data and or Personally Identifiable Information (PII) from ever being logged at the point of submission to Provider's APIs. Client Data submissions are accessed only momentarily in Random Access Memory (RAM), just long enough to process and deliver results back to Client. Upon completion of such process, any residual Client Data in the System’s RAM is dumped or "garbage collected" and written over by subsequent transactions. Such processing methods render requests for data deletion, destruction, correction, blocking, or exportation back to Client not feasible due to the nature of the transitory process.

Yes, by default, the country is not changed with US verifications. To standardize output, populate the field "Fixed Name for USA Verifications" on the Configure page with "US" or "USA" or "United States" so that any time a US address is verified, it will use this term.

We do not recommend that you display the verified checkboxes. These fields are the indicators to our app as to whether the address is currently verified, so a user checking or unchecking the verified field would break the process. Rely on the "Status" fields for both billing and shipping.

of the otherWe recommend having only the Status formula field for each address, and adding any other of the optional fields that fits your business process. We recommend you review the list of these fields in the implementation guide internally, and make a decision as to which ones you want to map in order to collect this data, and of those, which ones you want to display to the users.

The address fields needed for verification are the Street, and then City + State, or the Zip code. Everything else would be populated by the verification process.

No, it is not instantaneous. Smarty.com gathers new updates from USPS and publishes them at the first of every month. However, these updates would not automatically be transferred into your Salesforce account. For example, if a new address is registered, and you had attempted to verify it before it was registered, it would show as "Bad or Blank Address" in your Salesforce org. It is only when you would try to verify it again, that it would then successfully be confirmed as a valid address.

For US locations, our verified addresses are CASS-Certified according to USPS standards. In similar fashion, each other country has its own standards that Smarty.com data follows.

The maximum length is entirely dependent on the fields you create in Salesforce. For standard address fields that come with Salesforce, here are the lengths:

Address.Street (TextArea, 255 characters)

Address.City (String, 40 characters)

Address.State (String, 80 characters)

Address.PostalCode (String, 20 characters)

Address.Country (String, 80 characters)

Punctuation is typically removed when the address is verified. So "100 Main St." would become "100 Main St"

No. The verification process will recognize some abbreviations, but upon verification, they will no longer be abbreviated.

No, it might still verify the address with them in there, but we have an optional field where the urbanization codes are placed upon verification.

Click on Gear Button -> Setup -> User -> Permission Sets. You will see 4 Options:

Address Verification (Admin) for admins needing to administer the app, Address Verification (User) - for all other users, and the two others are for Guest (running on sites) or Community users. To assign a permission set, select one of these four permission sets, then click on Manage Assignments. --> Click on Add Assignment. --> Add the user you want to give access to the Address Verification app. Save the Setting. (You can also set up a flow that automatically gives the permission set to a user on creation.)