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.
The map import process for implementation:
- Your organization provides a sample CSV file exported from your local systems.
- Omnilert then builds an import "data map" to handle data from your system's CSV file.
- You set up an FTP server and configure Omnilert to use it. (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.
What is a "Data map"?
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.
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).
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.
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 map.
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.
Is the process secured?
The FTP import process supports FTPS as well as SFTP. We encourage the use of secure file transfers!