There's two generals ways to handle this: with Record Level Access (RLA) and with scripting. With 200 users, RLA is always the most secure (how bad is it if one user sees another user's data?), but can be harder to understand. I'm assuming users can all access the same tables, but should only be looking at a subset of records, probably the ones they created?
With RLA, you configure access through Manage Security... With scripting, you set up scripts to control the record set.
Which one is better depends on what exactly you're trying to accomplish.
the users will see differnet kind of information that they need to support the customers (illness, bankinfo, reports).
The structure that we have is, that we splitt the countrie ro different distrikts. the managers must share the distrikts to the users.
So i need a admin site where the managers can share the distrikts to each persons or remove the persons from the distrikts.
I have create users, and i can log in to the system. the problem is currently that i can not define the script to find the ID from the users to fit this together with the distrikt codes.
My recommendaiton is that you have a Users table with basic public information about each person (e.g., name, telephone, email, etc.). Then you have to decide how you want to manage User ID's and Password's. You can have FileMaker Manage the User ID's and passwords and even use scripts to create new accounts and assign privileges. But generally, if you have 200 users, I bet you are already managing them through Active Directory (or Open Directory) for access to your LAN, email, etc. So it would be easier to just make use of that system than to create a whole new security system. Plus using Active Directory will mean that when they change their password for the LAN, it is also changing their password for FileMaker and they don't have to update passwords in multiple places.
In the table with the Users info, you need to add a field for the Active Directory account name which will be what FileMaker sees when you do a Get(AccountName). That way you can connect a person loggin in with their information in the User table.
Using Active Directory, you can assign groups that are the privilege sets in FileMaker security. So the Managers can see some info that say the staff can't. You can also set up permissions so that they can see info only based on a calculation. For example, if you had a social security field, you could make a calcluation that says you can see this field if you are a manager or if you're Get(AccountName) equals whatever is in the User ID field of the employee table. That way one can see their own SSN, but not others, unless they are a manager. Or whatever formula you want.
I'll reiterate that you can manage FileMaker Users in FileMaker, but if you already have an Active Directory on your LAN, then I highly recommend you use it instead.