I don't think there is a more functional description.. But basically you need to a tenant identifier to all your tables and use for example dynamic procedures to automatically filter all tables based on the tenant logged in. You can use a session variable for this.

But I am also interested in best practices on this subject. @Mark Jongeling  

Not much to add @Freddy, that is indeed the way I would realize it.

Data is separated from other tenants by utilizing an On hidden prefilter (or data authorization prefilter - in Roles) that filters all data based on the Tenant. This could be obtained via session variables or by creating a table in your end product where all users are stored inside a tenant.

Session variables would have my preference as you can then more easily switch between tenants; for example when your an administrator.

First of all, make sure you have a clear plan of how you want to separate Tenants in your end product. Also ensure that Tenants cannot see any data of other Tenants; via main screens, details, look-ups, API and so on, it has to be hidden for others.

I wouldn't recommend just starting to build the application and then Agile your way to Production. It has to be fundamentally strong to ensure integrity and security of the data. Using Indicium will help a lot as you then do not have to give any users rights to the database itself.

Some considerations of when to use tenants or when not, can be found here.

Hope this helps! Any more questions, just post them here