Link Search Menu Expand Document

Build and use a robust import feature

Make a robust import feature that can be used for different entries.

You’ll have to populate a great deal of data

Adding things one by one gets very inefficient very quickly, such as adding thousands of products or tagging them to categories.

Building a robust import feature helps with this tremendously.

So, add an import feature

Initially, import might be rigid and the user might have to follow a provided template.

Rigid templates are not ideal. Once you start getting data from many different suppliers, converting things from one format to another takes a lot of time.

Implementing a robust feature is very useful because it makes it removes a lot of this work.

It also facilitates import for many different data types.

In Supplybunny, we started with a relatively robust structure and improved it over time. Eventually, it included the ability to import and create related entries as well.

There are three approaches with varying degrees of robustness.

Option 1: Flexible file upload with attribute mapping

The most robust is a flexible file upload that is most suitable for product import. A complete implementation includes the ability to upload CSV, XLS, or XLSX.

It would parse the headers and then allow the user to map headers to attributes.

It would also pre-populate the fields (for example, if the file contains a header Name, it would be automatically selected for the field name)

It would support create, update and delete operations. Deleting can be implemented by setting one of the fields to something like <<DELETE>>.

It would show a short preview of the changes. For instance, the first 10 rows will be shown with the existing and updated fields.

A history of uploaded files should be kept. Each row of each uploaded file should have a status indicating it’s progress.

It would also show any errors and, crucially, how the user should fix them.

Option 2: Template upload

Sometimes, when making an upload feature for users, the objective is often to provide a degree of self-service. We found that being more strict with the template and the accepted inputs more effective for that purpose.

The template should contain all the fields that can be uploaded. It should contain an example entry that should ideally be ignored by the upload.

You should explain each field. Include its data type (string, integer, float, etc.), and good and bad examples. You should also explain any validations that the system has, such as rejecting emojis or limiting the number of characters.

When the file is uploaded, first check that all the headers and fields are still there. This ensure that the integrity of the template.

Then process each line individually.

After all the lines are processed, show a summary of the successful changes.

Indicate if there were any failures and how to fix them. The user must be able to download the template with only failed entries. That way they can make changes to only the required entries.

Finally, for admins, pasting links has been found to work well for some features.

For instance, if the admin is adding a product to a group, they’d often have to go to add screen and then search for the product, often parsing through a long list of results.

Instead, the add screen can have a textarea where the user can paste one link per line.

After the user saves, the input is split into individual lines, trimmed, and parsed as routes.


Suggest an improvement to this page (me@ognjen.io)