I am working on a project which will be used by many Customers and these may have many branch offices, I am working on having one SQL2005 database for everybody, but of course the end users will only be able to see data from their Customer ID and Branch Office ID.

When login to the application I need to capture the Customer ID and Branch Office ID in the Login form, but how to filter the RBS data per Customer ID and Branch Office ID, so when the managers of one office creates an user and assign roles will only be able to do so for their records?

What would be the best approach to handle this with SF RBS?

Thanks!

However, even if you want to keep all customer data in the same database, you will still want to keep seperate security databases for each user, and dynamically specify the securitydatasourcekey depending on their Customer # + Branch Office ID combination. You would need one security database for each user, but that would give you the flexibility you need while still keeping your live data in the same database .

Is this approach a local database at each Customer server? (assumming they have a server :hehe or in your own server you have one database per customer?

However, even if you want to keep all customer data in the same database, you will still want to keep seperate security databases for each user, and dynamically specify the securitydatasourcekey depending on their Customer # + Branch Office ID combination. You would need one security database for each user, but that would give you the flexibility you need while still keeping your live data in the same database .

Do you mean if I have 200+ Customers, I would need 200+ security databases? that does not make sense, that would be hardly impossible to manage.

Basically all I need to is to control each customer License or Access to the database, also for managing purpose I would like to host all data at my hosting server, but I would not get into creating one database per customer at my hosting.  Any other ideas?

If that doesn't fit your needs, however, the other option is to extend the vanilla RBS to include your customer number and branch office within the SFSUsers table and BO. You would then need to extend the SFSUsers BO fill methods to only bring in user records for the currently active customer and branch office.

Humm, very interesting, so you won't do the maintenance of structure yourself, it will be a responsibility of an update to be run from the customer application using DDT.

If I go this way and modify the SFSUsers table, will this be break by any future SF update?

What about making a related table to SFSUsers which holds information on Branch and Customer. Relate it one-to-one to SFSUsers primary key. Make a form in your application to maintain these data, then you are clear of future SF updates.

/Teddy

That may work, even though still I would need to modify the security form, so when Customer X creates users, my related table would be updated with the Customer ID and Branch ID info, or at least just the Customer ID.