Omnilert offers a wide range of data management options, ranging from opt-in forms to file uploads and APIs. Many organizations choose to upload subscriber data into Omnilert.
Note: Read more about Opt-In vs. Opt-Out
When following an opt-out implementation, one option is what we call "mapped data imports." This provides a convenient way to automate the management of subscriber information in Omnilert, making your internal databases the "system of record" for contact information.
What is a "Data map"?
A "data map" is a process where Omnilert's engineers receive a sample of your CSV file, which is typically exported from your local data systems (e.g. an HR or student information database).
To push data to Omnilert, it must be presented in a simple CSV (Comma Delimited Text) file. Each subscriber gets a row in the file with the relevant info in it, such as username, first name, last name, phone number, email, etc. Of course, the data provided depends on what you have available and wish to include in Omnilert.
Omnilert then reviews the sample and builds a "map", mapping each of your data fields onto Omnilert's data fields.
It's OK if your system exports data with its own column names and order. We'll build the map to suit your layout.
The result is a special CSV file name assigned to you by Omnilert. This is what you'll need to name your CSV file, as it will tell Omnilert how to process your data (using your map, of course!)
The CSV file should always be a full, complete subscriber data set and should include every subscriber, device, etc.
How it works
- Omnilert will retrieve your mapped CSV file via FTP. (See FTP Import)
- The mapped CSV file must have its designated filename. The file will always use the same filename as assigned by Omnilert.
- The mapped CSV file must be present in its designated FTP folder
- When a mapped CSV file is found, Omnilert compares that file to the previous copy of your CSV.
- Any new records are added.
- Any missing records are deleted.
- Any new devices are added
- Any missing devices are deleted
- Any changed first/last names of subscribers are updated
- Any other mapped subscriber info: groupings, tags, languages, etc. are updated according to the mapping.
It is important to note that this process does not overwrite your Omnilert database each time.
Rather, the Omnilert system compares the CSV file to the previous copy and then applies the delta (changes) to the Omnilert system's subscriber data. If your mapped CSV file is identical from one copy to the next, then no changes are applied to the Omnilert data.
As such, subscriber accounts that are created outside of the mapped file will not be affected by the map processing so long as their usernames never appear in the mapped CSV file.
However, when using a mapped import management process, it's strongly to maintain all subscribers and subscriber data (groups, devices, etc) via the mapped process to avoid any possible conflicts or any data being lost if mapped data becomes out of sync due to a bad CSV file or incorrect data load.
We also recommend disabling the Subscriber Portal and managing everything through your mapped CSV when using a mapped implementation.
Mapped Import Process: Setup/Implementation Overview
The map import process for implementation is fairly simple. Your Omnilert account manager will guide you through each step of the way. Here is a rundown of the steps to implement:
- Your organization provides a sample CSV file exported from your local systems to your account manager.
- Omnilert then builds an import "data map" to handle data from your system's CSV file. This will tell Omnilert what columns to expect in your CSV file.
- You set up an FTP server and configure Omnilert to use it to retrieve CSV files. (See FTP Import)
- (Optional) A small-scale test with a dozen records is strongly recommended to ensure that your data map correctly pulls in subscriber data as desired before live production begins.
- Once ready, place a full CSV file of subscriber data on the FTP server in the appropriate folder with the appropriate file name.
- Then you set a schedule for file pickups per the FTP import instructions and let Omnilert handle changes to the data.
You'll need to host your own FTP server for this implementation. Omnilert will act as an FTP client, connecting to and retrieving your file, then returning receipts/logs after the file is processed.
Settings for the FTP client are configured in the Settings >> FTP Import section.
When mapping, the most important folder is the "Map compare files directory". This is the directory on your FTP server in which you must put your subscriber data (CSV file), with the assigned map name.
See the FTP Import instructions for the detailed setup instructions for Omnilert's FTP client.
Are we a good candidate for mapped implementation?
Mapping isn't right for every organization. Not every organization collects mobile data, email addresses, etc.
Data maps tend to work best if you have the following:
- Subscriber data you can export: Of course, in order to do any opt-out implementation, you have to have subscriber data. You'll need to be able to export it to a CSV format for Omnilert to process. If you have the resources to export that data to CSV, mapping might be a good option.
- A way to keep that subscriber data up-to-date: We often see cases where organizations think they have complete data, but it's actually quite out-of-date. Phone numbers won't do much good if they aren't current, of course. Do you keep contact info updated in your internal systems? If not, mapping might not be a good fit.
- FTP server: You're going to need an FTP server (or access to a secure FTP service) for Omnilert to connect and retrieve CSV files. Most organizations have this available, but be sure to check with your IT department to make sure.
If a map isn't the right path, then Omnilert offers a wide array of "opt-in" options.
What should be in the mapped CSV file?
Everything about your subscribers; usernames, first/last names, groups, devices, etc.
The file should be a cumulative file of the current subscriber data you'd like Omnilert to have. So, include every record you have with every mapped CSV file.
Do we need to track changes to the data?
This process is designed so that Omnilert will track changes based on the CSV file content. If a subscriber's username is in the mapped CSV file, it will be tracked by the map process.
This means if a subscriber who was in the file one day isn't there the next, Omnilert will delete their record. If their data changes from one file to the next, Omnilert updates their record. If there's a new username in the file, Omnilert will import them as a new subscriber record.
Do we still allow subscribers to log into Omnilert?
In this style of implementation, we want all of the subscriber data to come in via your CSV file. So, you should have a mechanism to allow subscribers to keep their info current in your internal systems. For example, if you're pulling data from an HR system, make sure your subscribers update their contact info in that system, so their updates will push to Omnilert through your mapped upload.
What happens if a subscriber texts 'STOP'?
The STOP command will be honored by Omnilert. Omnilert will stop sending SMS text messages to that number, unless it's removed and then re-added through your CSV file, of course.
What happens if our data gets "out of sync"?
In the event that something goes awry with the CSV file provided, the re-sync process is fairly simple.
In most cases, simply placing a new, corrected CSV on the FTP server will re-sync and fix the issue. If needed, Omnilert can assist you in wiping and reloading a fresh CSV file.
Does this process require that we use FTP/FTPS or SFTP?
Yes. FTP is the method Omnilert will use to retrieve your CSV file. You must have an FTP server that Omnilert can connect to. (See FTP Import)
Is the process secured?
The FTP import process supports FTPS as well as SFTP. We encourage the use of secure file transfers!