The best practice guidance for SQL Server security is to use roles for permissions, instead of granting rights to users. I've always followed this guidance in my career. I've learned that if one person needs access, sooner or later someone else will. Even if it's an automated process, I'll use a role so that I can build a test login to ensure I've configured things correctly.

In small companies, or in relatively static applications, this makes perfect sense and few people argue with the rule. That is, until they get some requirement that only one account will ever be used. Then they want to just grant rights to a user. After all, why add the role for one person. See my thought above. Sooner or later, someone else will want access.

However I also have had people complain that if each new required position or process needs their own role, sooner or later we'll have this proliferation of dozens of roles.

True.

I worked in a large Fortune 100 company and we had thousands of groups in our AD forest, and easily dozens of roles in many databases. While that might seem complex and confusing, it wasn't bad. We named roles to match AD groups or job functions, and adding in new users was simple as we usually mapped them to the same roles as a previous user. If a new system or person needs access, usually their access is the same as some other account.

However, I know they can be complex, so I'm wondering if you have any tips, tricks, hints, or even gotchas for using roles. I'd also be curious if you think there are cases where roles don't make sense.