پیش از نام‌گذاری نقش‌ها، مسئولیت‌ها را ترسیم کنید
با فهرستی از فعالیت‌ها داخل یک سازمان مشتری شروع کنید: مشاهده گزارش‌ها، دعوت از همکاران، ویرایش یکپارچه‌سازی‌ها، آماده‌سازی درخواست‌ها و تأیید تغییرات حساس. برای هر فعالیت، دلیل تجاری و رکوردهایی را که تحت تأثیر قرار می‌دهد مشخص کنید. سپس مسئولیت‌های سازگار را در نقش‌هایی گروه‌بندی کنید که مدیر بتواند بدون نمودار توضیحشان دهد. صرفاً به‌خاطر راحتی در زمان توسعه، یک نقش مدیرِ همه‌کاره نسازید. ممکن است کارشناس گزارش‌گیری به دید کامل تاریخی نیاز داشته باشد، اما هیچ اختیاری برای تغییر تنظیمات نداشته باشد. برای هر نقش، یک نمونه اقدام مجاز و یک نمونه اقدام غیرمجاز بنویسید. همین نمونه‌ها بعداً به کنترل‌های پذیرش مفید تبدیل می‌شوند.
مرزهای سازمان را صریح نگه دارید
یک فرد می‌تواند عضو چند سازمان باشد؛ بنابراین شناسه حساب به‌تنهایی برای تصمیم‌گیری درباره دسترسی کافی نیست. هر درخواست مرتبط باید سازمان فعال را مشخص کند و عضویت را نسبت به منبع درخواستی بررسی کند. همین مرز را برای خروجی‌ها، نتایج جست‌وجو، کارهای پس‌زمینه و لینک‌های پیوست نیز اعمال کنید. تغییر انتخابگر فضای کاری نباید داده‌های شرکت قبلی را روی صفحه باقی بگذارد. با دو سازمانی آزمایش کنید که نام پروژه‌های مشابه و اعضای تیم مشترک دارند. کاربری را هم در آزمون بگنجانید که هنگام آماده‌سازی گزارش، عضویتش را از دست می‌دهد. تصمیم بگیرید آن گزارش باید کامل شود، کنار گذاشته شود یا پیش از دانلود به مجوزگیری تازه نیاز داشته باشد.
دعوت‌ها و خروج افراد را به‌عنوان گردش‌کار ببینید
دعوت‌نامه به گیرنده، نقش پیشنهادی، تاریخ انقضا و وضعیت قابل مشاهده نیاز دارد. توضیح دهید اگر گیرنده از قبل حساب داشته باشد یا دعوت را با حساب اشتباه بپذیرد چه اتفاقی می‌افتد. دسترسی دارای امتیاز نباید فقط به این دلیل فعال شود که کسی یک لینک دعوت قدیمی در اختیار دارد. خروج فرد چیزی فراتر از پنهان کردن کاربر از یک فهرست است: نشست‌های فعال، اعتبارنامه‌های API شخصی، خروجی‌های زمان‌بندی‌شده و مالکیت منابع مشترک را بررسی کنید. حذف دسترسی را از پاک کردن کارهای تاریخی جدا نگه دارید. پیش از حذف آخرین مالک، انتقال آگاهانه مالکیت یا یک مسیر بازیابی تعریف‌شده دیگر را الزامی کنید. ثبت کنید چه کسی هر تغییر را انجام داده و با چه اختیاری آن را اعمال کرده است.
تغییرات مجوز را قابل بازبینی کنید
پیش از ذخیره تغییر نقش، پیامدهای آن را به مدیران نشان دهید؛ به‌ویژه وقتی دسترسی به سوابق مالی یا تنظیمات یکپارچه‌سازی را اعطا می‌کند. تاریخچه‌ای خوانا نگه دارید که شامل عامل تغییر، سازمان هدف، نقش قبلی، نقش جدید و زمان باشد. رکوردهای ممیزی باید پس از تغییر نام نمایشی نیز همچنان مفید بمانند. دسترسی را هم در سرور و هم در رابط کاربری آزمایش کنید؛ دکمه پنهان‌شده مرز مجوزدهی نیست. در پایان، یک تمرین کوتاه با تیم پشتیبانی انجام دهید: تشخیص دهید چرا کاربر نمی‌تواند کاری را کامل کند، بدون اینکه به‌عنوان میان‌بُر مجوزهای گسترده‌تر به او بدهید. مدل نهایی باید قابل فهم، قابل آزمون و در عملیات روزمره عملی باشد.