ਬਹੁ-ਟੇਨੈਂਟ SaaS ਅਧਿਕਾਰ: ਸੰਗਠਨ, ਟੀਮਾਂ, ਰੋਲ ਸਪਸ਼ਟ

ਹدف ਸਧਾਰਨ ਹੈ: ਅਣੁਮਾਨਕ ਅਤੇ ਪੇਸ਼ਗੋਈ ਯੋਗ ਅਕਸੇਸ ਨਿਯਮ ਜੋ ਤੁਸੀਂ ਇਕ ਮਿੰਟ ਵਿੱਚ ਸਮਝਾ ਸਕੋ۔ ਉਦਾਹਰਣ: "ਤੁਹਾਡੀ ਸੰਗਠਨ ਡੇਟਾ ਦੀ ਮਾਲਿਕ ਹੈ۔ ਟੀਮਾਂ ਲੋਕਾਂ ਨੂੰ ਗ੍ਰੁੱਪ ਕਰਦੀਆਂ ਹਨ۔ ਰੋਲ ਕਾਰਵਾਈਆਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ۔ ਸਰੋਤ ਇੱਕ ਸੰਗਠਨ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਦੇ-ਕਦੇ ਇੱਕ ਟੀਮ ਨਾਲ। ਸਾਂਝੇ ਕਰਨਾ ਕੁਝ ਫ਼ੈਲਟਸ ਦੇ ਅਨੁਸਾਰ ਹੁੰਦਾ ਹੈ۔" ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਫ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਉਸਨੂੰ ਬਣਾਉਣਾ, ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ۔

ਇੱਕ ਵਾਅਦਾ ਜੋ ਰੱਖਣ ਲਾਇਕ ਹੈ: ਘੱਟ ਰੋਲ, ਸਪਸ਼ਟ ਮਲਕੀਅਤ, ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ। ਸੱਚੇ ਕੰਮ-ਨਿਭਾਉਂਦੇ ਰੋਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹਰ ਸਰੋਤ ਲਈ ਮਲਕੀਅਤ ਆਸਾਨੀ ਨਾਲ ਦੇਖਣਯੋਗ ਬਣਾਓ, ਅਤੇ ਸਬ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ۔ ਫਿਰ ਇਰਾਦੇ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ, ਅਖ਼ਤਿਆਰੀ ਤੌਰ ’ਤੇ ਨਹੀਂ۔

ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ ਨਕਸ਼ਾ: ਸੰਗਠਨ, ਟੀਮਾਂ, ਉਪਭੋਗੀ ਅਤੇ ਸਰੋਤ

ਜੇ ਤੁਹਾਡੀ ਐਪ ਇੱਕ ਤੋਂ ਵੱਧ ਗਾਹਕਾਂ ਨੂੰ ਸੇਵਾ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਨਸਕ ਨਕਸ਼ਾ ਸਹੀ ਰੱਖੋ। ਬਹੁ-ਟੇਨੈਂਟ SaaS ਅਧਿਕਾਰਾਂ ਵਿੱਚ ਅਧਿਕਤਮ ਗਲਤੀ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੇ ਪਰਸਾਰ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਜਿੱਥੇ ਇੱਕੋ ਸ਼ਬਦ ਉਤਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਤਲਬ ਰੱਖਦਾ ਹੈ۔

ਆਪਣਾ ਟੇਨੈਂਟ ਬਾਉਂਡਰੀ ਲਈ ਇੱਕ ਮਤਲਬ ਚੁਣੋ ਅਤੇ ਉਸ ਤੇ ਟਿਕੇ ਰਹੋ। ਬਹੁਤੀਆਂ ਉਤਪਾਦ "organization" ਨੂੰ ਟੇਨੈਂਟ ਵਜੋਂ ਵਰਤਦੇ ਹਨ: ਸਾਰਾ ਡੇਟਾ ਇੱਕ ਆਰਗ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਉਸ ਲਕੀਰ ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰਦਾ ਜਦ ਤੱਕ ਤੁਸੀਂ ਖਾਸ ਤੌਰ ’ਤੇ ਸਾਂਝਾ ਕਰਨ ਦੀ ਬਣਾਣੀ ਨਹੀਂ ਕਰਦੇ।

ਇੱਕ ਸਧਾਰਣ ਸ਼ਬਦ-ਭੰਡਾਰ ਜੋ ਵੱਧਣ ਦੇ ਨਾਲ ਵੀ ਸਪਸ਼ਟ ਰਹੇ:

• ਸੰਗਠਨ (ਟੇਨੈਂਟ): ਗਾਹਕ ਖਾਤਾ ਅਤੇ ਕਠੋਰ ਡੇਟਾ ਬਾਊਂਡਰੀ।
• ਉਪਭੋਗੀ (ਪਹਚਾਨ): ਇੱਕ ਵਿਅਕਤੀ ਜਿਸਦਾ ਇੱਕ ਲਾਗਿਨ ਹੁੰਦਾ ਹੈ।
• ਮੈਂਬਰਸ਼ਿਪ: ਉਹ ਲਿੰਕ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਉਪਭੋਗੀ ਕਿਸ ਆਰਗ ਦਾ ਮੈਂਬਰ ਹੈ, ਅਤੇ ਉਸਦਾ ਰੋਲ(ਆਂ)।
• ਟੀਮ (ঐচ্ছਿਕ): ਆਰਗ ਦੇ ਅੰਦਰ ਦੈਨੀਕ ਕੰਮ ਲਈ ਗ੍ਰੁੱਪਿੰਗ।
• ਸਰੋਤ: ਕੋਈ ਵੀ ਚੀਜ਼ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਰੱਖਣੀ ਹੈ (ਪ੍ਰੋਜੈਕਟ, ਇਨਵੈਂਸ, ਟਿਕਟ, API ਕੀ)।

"ਇੱਕ ਵਿਅਕਤੀ, ਬਹੁਤ ਸਾਰੀਆਂ ਆਰਗਾਂ" ਆਮ ਹੈ। ਇਕ ਸਲਾਹਕਾਰ ਤਿੰਨ ਗਾਹਕ-aarਗਾਂ ਦਾ ਮੈਂਬਰ ਹੋ ਸਕਦਾ ਹੈ, ਹਰ ਇੱਕ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਰੋਲ। ਇਸੀ ਲਈ "ਉਪਭੋਗੀ" ਅਤੇ "ਮੈਂਬਰਸ਼ਿਪ" ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਤੁਹਾਡੀ ਜਾਂਚ ਆਮ ਤੌਰ ਤੇ ਮੈਂਬਰਸ਼ਿਪ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀ ਹੈ, ਨ ਕਿ ਸਿਰਫ ਉਪਭੋਗੀ 'ਤੇ।

ਜਦ ਟੀਮਾਂ ਅਸਲ ਗ੍ਰੁੱਪਿੰਗ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਜਿਵੇਂ "Support" ਜਾਂ "Finance", ਤਾਂ ਉਹ ਮਦਦਗਾਰ ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਉਹ ਦੂਜੇ ਅਧਿਕਾਰ ਪ੍ਰਣਾਲੀ ਬਣ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਓਹ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ۔ ਇੱਕ ਉਪਯੋਗੀ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਟੀਮ ਨੂੰ ਇਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਖਾਸ ਫੀਚਰ ਨਿਯਮ ਦਾ ਜ਼ਿਕਰ ਕੀਤੇ।

ਉਦਾਹਰਣ: ਮਾਰੀਆ ਇਕ ਵਾਰੀ ਲੌਗ ਇਨ ਕਰਦੀ ਹੈ, ਫਿਰ Org A ਅਤੇ Org B ਵਿਚੋਂ ਸਵਿੱਚ ਕਰਦੀ ਹੈ। Org A ਵਿੱਚ ਉਹ Finance ਵਿੱਚ ਹੈ ਅਤੇ ਇਨਵੌਇਸ ਵੇਖ ਸਕਦੀ ਹੈ। Org B ਵਿੱਚ ਉਹ Viewer ਹੈ ਅਤੇ ਸਿਰਫ ਪ੍ਰੋਜੈਕਟ ਪੜ੍ਹ ਸਕਦੀ ਹੈ। ਇਕੋ ਉਪਭੋਗੀ, ਵੱਖ-ਵੱਖ ਮੈਂਬਰਸ਼ਿਪ, ਸਪਸ਼ਟ ਬਾਊਂਡਰੀ।

ਰੋਲ, ਅਧਿਕਾਰ ਅਤੇ ਸਕੋਪ ਬਿਨਾਂ ਜਾਰਗਨ ਦੇ

ਬਹੁ-ਟੇਨੈਂਟ SaaS ਅਧਿਕਾਰ ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦੇ ਹੋ:

• ਰੋਲ: ਜਿੰਨੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦੀ ਲੇਬਲ।
• ਪਹੁੰਚ/ਅਧਿਕਾਰ: ਜੋ ਕੋਈ ਕਰ ਸਕਦਾ ਹੈ।
• ਸਕੋਪ: ਕਿੱਥੇ ਉਹ ਇਹ ਕਰ ਸਕਦਾ ਹੈ۔

ਸਧਾਰਨ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ RBAC

RBAC (role-based access control) ਦਾ ਮਤਲਬ ਹੈ: ਤੁਸੀਂ ਇਕ ਉਪਭੋਗੀ ਨੂੰ ਰੋਲ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਉਹ ਰੋਲ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਾਰਵਾਈਆਂ ਦਿੰਦਾ ਹੈ۔ ਰੋਲ ਨਾਂ ਜਿੰਮੇਵਾਰੀ ਨੂੰ ਦਰਸਾਉਣੇ ਚਾਹੀਦੇ ਹਨ, ਹਾਲਤ ਨੂੰ ਨਹੀਂ۔ "Billing Admin" ਸਪੱਸ਼ਟ ਹੈ। "Power User" ਅਕਸਰ ਬਹਿਸ ਪੈਦਾ ਕਰਦਾ ਹੈ۔

ਅਧਿਕਾਰਾਂ ਨੂੰ ਕਿਰਿਆ-ਪਦ ਵਰਗੇ ਸੌਖੇ ਰੱਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੂਰੇ ਉਤਪਾਦ ਵਿੱਚ ਸਤਤ ਰੱਖੋ:

• View (ਪੜ੍ਹੋ)
• Create (ਬਣਾਓ)
• Edit (ਸੋਧੋ)
• Delete (ਹਟਾਓ)
• Manage (ਨਿਮੰਤਰਣ, ਸੈਟਿੰਗਸ, export ਆਦਿ)

ਫਿਰ ਸਕੋਪ ਜੋੜੋ ਤਾਂ ਜੋ ਇੱਕੋ ਕਿਰਿਆ ਵੱਖ-ਵੱਖ ਸਥਾਨਾਂ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕੇ। ਇਹੀ ਤਰੀਕਾ ਤੁਹਾਨੂੰ 20 ਥੋੜ੍ਹੇ ਬਦਲ ਰੋਲਾਂ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ۔

ਆਮ ਸਕੋਪ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੇ ਹਨ:

• ਆਰਗ-ਵਿਆਪਕ
• ਟੀਮ-ਮਾਤਰ
• ਆਪਣੀ ਵਸਤੂਆਂ
• ਨਿਯੁਕਤ (Assigned)

ਜਦੋਂ ਮਲਕੀਅਤ ਇੱਕ ਹੋਰ ਰੋਲ ਬਣਾਉਣ ਨਾਲ ਬਿਹਤਰ ਹੈ

ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਰੋਲ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ "Project Editor" ਅਤੇ "Project Editor (Own)" ਵਰਗੇ ਰੋਲ ਬਣਾਉਣ ਲੱਗੋ, ਤਾਂ ਇਹ ਅਕਸਰ ਸਕੋਪ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਰੋਲ ਦੀ ਨਹੀਂ।

ਉਦਾਹਰਣ: ਇੱਕ CRM ਵਿੱਚ, "Sales Rep" ਨੂੰ ਸੌਂਪੋ ਕਿ ਉਹ ਡੀਲ ਬਣਾਏ ਅਤੇ ਸੋਧੇ, ਪਰ ਸਕੋਪ "own items" ਤੱਕ ਸੀਮਿਤ ਕਰੋ। "Sales Manager" ਨੂੰ ਉਹੀ ਕਿਰਿਆਵਾਂ ਦਿਓ ਪਰ "team-only" ਜਾਂ "org-wide" ਸਕੋਪ ਦੇ ਨਾਲ। ਤੁਹਾਨੂੰ ਘੱਟ ਰੋਲ, ਸਪਸ਼ਟ ਨਿਯਮ ਅਤੇ ਘੱਟ ਹੈਰਾਨੀ ਮਿਲੇਗੀ ਜਦੋਂ ਕੋਈ ਟੀਮ ਬਦਲਦੀ ਹੈ।

ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫਾਲਟ ਇਹ ਹੈ: ਰੋਲ ਕਿਰਿਆਵਾਂ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਮਲਕੀਅਤ (ਜਾਂ ਨਿਯੁਕਤੀ) ਇਹ ਨਿਯਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਕੰਮ ਕਰੇਗੀ۔

ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ-ਸੈਟ ਜੋ ਸੈਂਕੜਿਆਂ ਆਰਗਾਂ ਤੇ ਸਕੇਲ ਕਰਦਾ ਹੈ

ਜੇ ਤੁਹਾਡਾ ਮਾਡਲ ਇੱਕ ਗਾਹਕ ਲਈ ਚੰਗਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਪਰ ਦੱਸ ਤੱਕ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ "ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ" ਨੂੰ "ਕੌਣ ਕਰ ਸਕਦਾ ਹੈ" ਅਤੇ "ਕੌਣ ਮਲਿਕ ਹੈ" ਨਾਲ ਮਿਲਾ ਦਿੱਤਾ ਹੈ۔ ਇਹ ਤਿੰਨ ਗੱਲਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰੇਡੀਕਟੇਬਲ ਰਹੇਗਾ।

ਇੱਕ ਐਸਾ ਨਿਯਮ-ਸੈੱਟ ਜੋ ਸਕੇਲ ਹੁੰਦਾ ਹੈ:

• ਹਰ ਰਿਕਾਰਡ (ਪ੍ਰੋਜੈਕਟ, ਇਨਵੌਇਸ, ਟਿਕਟ, API ਕੀ) ਦਾ ਇਕ ਸਟੀਕ ਹੋਮ ਆਰਗ ਹੁੰਦਾ ਹੈ।
• ਇੱਕ ਉਪਭੋਗੀ ਸਿਰਫ ਉਹਨਾਂ ਆਰਗਾਂ ਦਾ ਡੇਟਾ ਦੇਖ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਸਖ਼ਤੀ ਨਾਲ ਆਕਟਿਵ ਮੈਂਬਰ ਹੈ۔ ਜੇ ਉਹ ਮੈਂਬਰ ਨਹੀਂ, ਤਾਂ UI ਅਤੇ API ਨੂੰ ਉਸ ਆਰਗ ਨੂੰ ਮੌਜੂਦ ਨਾ ਸਮਝਣਾ ਚਾਹੀਦਾ।
• ਰੋਲ ਕਾਰਵਾਈਆਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ (ਬਣਾਉਣਾ, ਸੋਧਣਾ, ਹਟਾਉਣਾ, export), ਪਰ ਕੇਵਲ ਉਹਨਾਂ ਆਰਗਾਂ ਵਿੱਚ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਪਭੋਗੀ ਪਹਿਲਾਂ ਹੀ ਦੇਖ ਸਕਦਾ ਹੈ۔
• ਮਲਕੀਅਤ ਫੈਸਲਾ ਕਰਨ ਵਾਲੀ tie-breaker ਹੁੰਦੀ ਹੈ। ਇਹ ਆਗਿਆ ਦੇ ਸਕਦੀ ਹੈ ਕੁਝ ਵਾਧੂ ਹੱਕ ਬਰابر ਸਕੋਪ ਦੇ ਅੰਦਰ (ਆਪਣਾ ਡਰਾਫਟ ਸੋਧੋ, ਆਪਣੀ API ਟੋਕਨ ਪ੍ਰਬੰਧਿਤ ਕਰੋ) ਬਿਨਾਂ ਹੋਰ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਵਧਾਏ।
• ਐਡਮਿਨ ਐਕਸੈਸ ਇੱਕ ਤੰਗ, ਖੁੱਲ੍ਹਾ ਛੂਟ ਹੈ। ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ "admin" ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਐਡਮਿਨ-ਪੱਧਰੀ ਰੋਲਾਂ ਘੱਟ ਰੱਖੋ۔

ਉਦਾਹਰਣ: ਸੈਮ Org A ਅਤੇ Org B ਦਾ ਮੈਂਬਰ ਹੈ۔ Org A ਵਿੱਚ ਸੈਮ Member ਹੈ ਅਤੇ ਉਹ ਆਪਣੀਆਂ ਰਿਪੋਰਟਾਂ ਬਣਾਕੇ ਸੋਧ ਸਕਦਾ ਹੈ ਪਰ ਬਿਲਿੰਗ ਨਹੀਂ ਬਦਲ ਸਕਦਾ۔ Org B ਵਿੱਚ ਸੈਮ Billing Manager ਹੈ ਅਤੇ ਉਹ ਭੁਗਤਾਨ ਤਰੀਕੇ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਨਵੌਇਸ ਡਾਉਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ، ਪਰ ਫਿਰ ਵੀ ਉਹ ਪ੍ਰਾਈਵੇਟ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਜਦ ਤੱਕ ਉਸਦੀ ਮੈਂਬਰਸ਼ਿਪ ਉਸ ਖੇਤਰ ਨੂੰ ਸ਼ਾਮਿਲ ਨਹੀਂ ਕਰਦੀ।

ਇਸ ਨਾਲ ਵੱਧਣਾ ਅਚਾਨਕ ਬੋoring ਬਣ ਜਾਂਦਾ ਹੈ—ਵਧਾਉਣਾ ਸਿਰਫ ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ ਰੋਲਾਂ ਜੋੜਨਾ ਹੁੰਦਾ ਹੈ। ਮੁੱਖ ਨਿਯਮ ਇੱਕੋ ਹੀ ਰਹਿੰਦੇ ਹਨ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਪੰਨੇ 'ਤੇ ਆਪਣੀ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਡਿਜ਼ਾਇਨ ਕਰੋ

ਇੱਕ ਸਫ਼ਾ ਲਿਖੋ ਜੋ ਕੋਈ ਸਾਥੀ ਦੋ ਮਿੰਟ ਵਿੱਚ ਪੜ੍ਹ ਸਕੇ। ਜੇ ਤੁਸੀਂ ਕੋਡ ਖੋਲ੍ਹਣ ਤੋਂ ਬਿਨਾਂ ਅਧਿਕਾਰ ਸਮਝਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਧੀਆ ਹਾਲਤ ਵਿੱਚ ਹੋ۔

1) ਨਿਯਮਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇਨਪੁੱਟ ਲਿਖੋ

ਭਾਗਾਂ ਨੂੰ ਜਾਨਬੂਝ ਕਰਕੇ ਛੋਟਾ ਰੱਖੋ:

• ਚਾਰ ਉਪਭੋਗੀ ਕਿਸਮਾਂ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਸਮਝਾ ਸਕਦੇ ਹੋ: owner, admin, member, viewer.
• 3-6 ਸਰੋਤ ਲਿਸਟ ਕਰੋ ਜੋ ਲੋਕ ਦਿਨਚਰਿਆ ਵਿੱਚ ਛੂਹਦੇ ਹਨ (projects, customers, reports, billing).
• ਹਰ ਸਰੋਤ ਲਈ 2-4 ਕਾਰਵਾਈਆਂ ਲਿਖੋ (view, create, edit, delete, invite, export).
• ਨਵੇਂ ਮੈਂਬਰ ਨੂੰ ਡਿਫਾਲਟ ਕੀ ਮਿਲਦਾ ਹੈ ਫੈਸਲਾ ਕਰੋ (ਅਕਸਰ viewer ਜਾਂ member, admin ਨਹੀਂ).
• ਫੈਸਲਾ ਕਰੋ ਕਿ "ਟੀਮ" ਕੀ ਬਦਲਦੀ ਹੈ। ਇਸਨੂੰ visibility, ਨਿਯੁਕਤੀ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਤੱਕ ਸੀਮਤ ਰੱਖੋ—ਚੁਪਕੇ ਅਧਿਕਾਰ ਨਹੀਂ।

2) ਨਿਯਮਾਂ ਨੂੰ ਇਕ ਸਧਾਰਣ ਟੇਬਿਲ ਵਿੱਚ ਰੱਖੋ

ਰੋਲ ਐਕਸਪਲੋਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ ਸਕੋਪ ਵਰਤੋਂ। ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦਾਂ ਨੂੰ ਕੇਵਲ ਤਿੰਨ ਸਕੋਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: own, team, org.

ਸੈਨਟੀ ਚੈੱਕ: ਇਸ ਪੰਨੇ ਨੂੰ ਕਿਸੇ ਗੈਰ-ਟੈਕਨੀਕੀ ਸਾਥੀ ਨੂੰ ਦਿਖਾਉ ਅਤੇ ਪੁੱਛੋ, "ਕੀ Support member Sales ਰਿਪੋਰਟ ਸੋਧ ਸਕਦਾ ਹੈ?" ਜੇ ਉਹ ਹਿਚਕਿਚਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਸਕੋਪ ਜਾਂ ਟੀਮ ਦੀ ਪਰਿਭਾਸ਼ਾ ਸਪਸ਼ਟ ਨਹੀਂ।

ਸਰੋਤ ਮਲਕੀਅਤ ਅਤੇ ਸਾਂਝੇ ਕਰਨ ਦੇ ਨਿਯਮ ਜੋ ਸਧਾਰਣ ਰਹਿੰਦੇ ਹਨ

ਅਧਿਕਾਰਾਂ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਣ ਲਈ, ਹਰ ਸਰੋਤ ਦੀ ਮਲਕੀਅਤ ਨਿਰਧਾਰਤ ਕਰੋ, ਫਿਰ ਸਾਂਝੇ ਕਰਨ ਦੇ ਵਿਕਲਪ ਸੀਮਿਤ ਰੱਖੋ۔

ਡਿਫਾਲਟ ਮਲਕੀਅਤ ਮਾਡਲ

ਜ਼ਿਆਦਾਤਰ ਸਰੋਤਾਂ ਨੂੰ ਆਰਗ-ਮੈਲਕਾਨਾ ਬਨਾਓ। ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਨੀ ਦੀਆਂ ਧਾਰਣਾਵਾਂ ਵਿੱਚ ਸੋਚਦੇ ਹਨ: ਇਨਵੌਇਸ, ਪ੍ਰੋਜੈਕਟ, ਸੰਪਰਕ, ਟਿਕਟ, ਆਟੋਮੇਸ਼ਨ ਸੰਗਠਨ ਦੇ ਮਾਲਕ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਵਿਅਕਤੀਗਤ।

ਟੀਮਾਂ ਫਿਰ ਵੀ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਟੀਮ ਨੂੰ ਇੱਕ ਵਰਕਫਲੋ ਲੇਬਲ ਵਜੋਂ ਪ੍ਰਤੱਖ ਕਰੋ ਜੋ ਰੂਟਿੰਗ ਅਤੇ ਡਿਫਾਲਟ ਵਿਜ਼ੀਬਿਲਿਟੀ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਹਾਰਡ ਸੁਰੱਖਿਆ ਲਾਜਿਕ ਵਜੋਂ۔ ਟੀਮ ਟੈਗ ਫਿਲਟਰ, ਡੈਸ਼ਬੋਰਡ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਜਾਂ ਕਿਊਜ਼ ਚਲਾਉਣ ਵਾਸਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਦ ਕਿ ਅੈਕਸੈਸ ਫਿਰ ਵੀ ਰੋਲ ਅਤੇ ਸਕੋਪ ਤੋਂ ਆਉਂਦਾ ਹੈ।

ਉਪਭੋਗੀ-ਮਾਲਕ ਸਰੋਤ ਅਪਵਾਦ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਸਿਰਫ ਐਸੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਜੋ ਸੱਚਮੁੱਚ ਨਿੱਜੀ ਹਨ: ਡਰਾਫਟ, ਨਿੱਜੀ ਨੋਟਸ, ਸੇਵ ਕੀਤੇ ਵਿਊਅਜ਼, API ਟੋਕਨ, ਜਾਂ ਨਿੱਜੀ ਸੈਟਿੰਗ। ਜੇ ਕੋਈ ਉਪਭੋਗੀ ਛੱਡ ਕੇ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਕਰਨਾ ਹੈ: ਮਿਟਾਉਣਾ, ਟਰਾਂਸਫਰ ਕਰਨਾ, ਜਾਂ ਨਿੱਜੀ ਰੱਖਣਾ।

ਸਾਂਝੇ ਕਰਨ ਦੇ ਕੁਝ ਛੋਟੇ ਨਿਯਮ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੇ ਹਨ:

• ਡਿਫਾਲਟ ਆਰਗ-ਮਾਲਕ: ਆਈਟਮ ਇੱਕੋ organization ID ਹੇਠ ਸਟੋਰ ਕਰੋ।
• ਵਰਕਫਲੋ ਲਈ ਟੀਮ-ਟੈਗ: ਇੱਕ ਟੀਮ ਲਈ ਟੈਗ ਕਰੋ ਰੂਟਿੰਗ ਲਈ, ਸਖ਼ਤ ਐਕਸੈਸ ਨਹੀਂ।
• ਨਿੱਜੀ ਆਈਟਮ ਲਈ ਉਪਭੋਗੀ-ਮਾਲਕੀ: ਸਾਧਾਰਣ ਤੌਰ 'ਤੇ ਨਿੱਜੀ, ਜਦ ਤੱਕ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਾਂਝਾ ਨਾ ਕੀਤਾ ਜਾਵੇ।
• ਸਾਂਝੇ ਕਰਨ ਦੀਆਂ ਪੱਧਰਾਂ ਕੇਵਲ: Private (owner), Team, Org. ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ per-item ACLs ਤੋੜੋ।
• "ਅਸਾਈਨਡ ਟੂ" ਨੂੰ "ਦੀ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ" ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ: ਨਿਯੁਕਤੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ, ਅਧਿਕਾਰ ਨਹੀਂ।

ਅਜਿਹਾ ਸਾਂਝਾ ਕਰਨਾ ਜੋ ਸਧਾਰਣ ਰਹੇ

ਜਦੋਂ ਕੋਈ ਕਹਿੰਦਾ ਹੈ "ਮੈਨੂੰ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ," ਤਾਂ ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਹੜੇ ਪੱਧਰ 'ਤੇ ਹੈ: ਉਹਨਾਂ ਦੀ ਨਿੱਜੀ ਵਸਤੂ, ਉਹਨਾਂ ਦੀ ਟੀਮ ਦਾ ਕੰਮ, ਜਾਂ ਪੂਰੀ ਆਰਗ। ਜੇ ਇਹ ਤਿੰਨ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਅਕਸਰ ਇਹ ਸੂਚਨ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਕੋਪ ਸਪਸ਼ਟ ਨਹੀਂ, ਨਾ ਕਿ ਤੁਹਾਨੂੰ ਨਵਾਂ ਸਾਂਝਾ ਕਰਨ ਦਾ ਢੰਗ ਚਾਹੀਦਾ ਹੈ۔

ਉਦਾਹਰਨ: ਇੱਕ ਸਪੋਰਟ ਟਿਕਟ ਆਰਗ-ਮਾਲਕ ਹੋ ਸਕਦੀ ਹੈ (ਤਾਂ ਜੋ ਮੈਨੇਜਰ ਸਾਰੇ ਟਿਕਟਾਂ 'ਤੇ ਰਿਪੋਰਟ ਕਰ ਸਕਣ), Support ਨੂੰ ਟੀਮ-ਟੈਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਸੀਧੇ ਕਿਊ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਲਈ), ਅਤੇ Jordan ਨੂੰ ਅਸਾਈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਜੋ ਜਵਾਬਦੇਹੀ ਦਿਖਾਉਂਦਾ ਹੈ)। ਅਸਾਈਨਮੈਂਟ ਹੋਰ ਆਗਿਆਵਾਂ ਵਾਲੇ ਰੋਲਾਂ ਨੂੰ ਵੇਖਣ ਤੋਂ ਰੋਕਣੀ ਚਾਹੀਦੀ ਨਹੀਂ।

ਨਿਮੰਤਰਣ, ਮੈਂਬਰਸ਼ਿਪ ਬਦਲਣਾ, ਅਤੇ ਆਰਗਾਂ ਦੇ ਵਿਚਕਾਰ ਸਵਿੱਚ ਕਰਨਾ

ਅਧਿਕਾਰ ਅਕਸਰ "ਲੋਕ ਘਟਨਾਵਾਂ" ਦੌਰਾਨ ਟੁਟਦੇ ਹਨ: ਕਿਸੇ ਨੂੰ ਨਿਯੋਤਾ ਭੇਜਣਾ, ਉਹਨਾਂ ਨੂੰ ਟੀਮਾਂ ਵਿਚ ਘੁੰਮਾਉਣਾ, ਜਾਂ ਪਹੁੰਚ ਹਟਾਉਣਾ। ਇਹ ਫਲੋ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਮਾਡਲ ਅਣੁਮਾਨਕ ਰਹੇਗਾ ਜਾਂ ਨਹੀਂ۔

ਨਿਮੰਤਰਣ

ਇੱਕ ਨਿਮੰਤਰਣ ਨੂੰ ਮੈਂਬਰਸ਼ਿਪ ਬਣਾਉਣ ਦੀ ਬੇਨਤੀ ਵਜੋਂ ਵਰਤੋ, ਆਪਣੇ ਆਪ ਪਹੁੰਚ ਨਹੀਂ। ਨਿਮੰਜਰ ਨੂੰ ਆਰਗ, ਟੀਮ (ঐচ্ছਿਕ), ਅਤੇ ਰੋਲ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਿ ਸਵੀਕਾਰ ਕਰਨ ਤੇ ਮਿਲੇਗਾ۔

ਆਪਣਾ ਨਿਯਮ ਕਸੇ ਰੱਖੋ:

• ਕੇਵਲ ਖਾਸ ਰੋਲ ਨਿਮੰਤਰਣ ਭੇਜ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਣ ਲਈ, Owner ਅਤੇ Admin). ਜੇ ਤੁਸੀਂ ਟੀਮ ਲੀਡਸ ਸਹਿਯੋਗ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕੇਵਲ ਆਪਣੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਨਿਯੁਕਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ।
• ਨਿਯੋਤਾ ਕੇਵਲ ਉਹੇ ਰੋਲ ਦੇ ਸਕਦਾ ਹੈ ਜਿਹੜੇ ਉਸਦੇ ਆਪਣੇ ਲੈਵਲ ਤੋਂ ਥੱਲੇ ਜਾਂ ਬਰਾਬਰ ਹੋਣ।
• ਮਿਆਦ ਖਤਮ ਹੋ ਚੁੱਕੇ ਨਿਮੰਤਰਣ ਕੋਈ ਕੰਮ ਨਹੀਂ ਕਰਦੇ۔
• ਜੇ ਈਮੇਲ ਪਹਿਲਾਂ ਹੀ ਖਾਤੇ ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ, ਤਾਂ ਸਵੀਕਾਰ ਕਰਨ 'ਤੇ ਉਸਨੂੰ ਆਰਗ ਨਾਲ ਜੋੜ ਦਿਓ। ਨਹੀਂ ਤਾਂ, ਸਵੀਕਾਰ ਕਰਨਾ ਖਾਤਾ ਬਣਾਉਂਦਾ ਹੈ ਤੇ ਫਿਰ ਜੋੜਦਾ ਹੈ۔

ਅਸਥਾਈ ਪਹੁੰਚ ਇੱਥੇ ਫਿੱਟ ਹੁੰਦੀ ਹੈ ਵੀ۔ ਇਕ "ਟੈਮਪ ਯੂਜ਼ਰ" ਰੋਲ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਰੋਲ ਗ੍ਰਾਂਟ ਨੂੰ ਇੱਕ ਅਖੀਰ ਦੀ ਤਾਰੀਖ ਦੇਣ ਦੀ ਆਗਿਆ ਦਿਓ। ਜਦੋਂ ਉਹ ਆ ਜਾਂਦੀ ਹੈ, ਪਹੁੰਚ ਆਪਣੇ-ਆਪ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਏਗੀ ਅਤੇ ਆਡੀਟ ਟਰੇਲ ਸਾਫ਼ ਰਹੇਗੀ।

ਜੁੜਨਾ ਅਤੇ ਛੱਡਣਾ, ਬਿਨਾਂ ਮਲਕੀਅਤ ਗੁੰਮ ਕਰਨ ਦੇ

ਜਦੋਂ ਕੋਈ ਆਰਗ ਛੱਡਦਾ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਦੇ ਸਰੋਤਾਂ ਨਾਲ ਫੈਸਲਾ ਕਰਨਾ ਅੰਦਾਜ਼ਾ ਨਾ ਕਰੋ। ਜੇ ਤੁਹਾਡਾ ਨਿਯਮ "ਸਰੋਤ ਆਰਗ-ਮਾਲਕ ਹਨ," ਤਾਂ ਇਸ ਤੇ ਟਿਕੋ। ਵਿਅਕਤੀ ਨੂੰ ਇਤਿਹਾਸ ਲਈ ਬਣਾਇਆ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਪਰ ਆਰਗ ਮਾਲਕ ਰਹੇਗਾ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਉਪਭੋਗੀ-ਮਾਲਕ ਸਰੋਤ ਹਨ, ਤਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਆਈਟਮਾਂ (ਪ੍ਰੋਜੈਕਟ, ਦਸਤਾਵੇਜ਼, API ਕੀ) ਲਈ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟਰਾਂਸਫਰ ਲਾਜ਼ਮੀ ਕਰੋ۔

ਆਰਗ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਬਦਲਣਾ

ਇੱਕ ਲਾਗਿਨ ਬਹੁਤ ਸਾਰੀਆਂ ਆਰਗਾਂ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ, ਪਰ ਐਪ ਨੂੰ ਹਮੇਸ਼ਾ ਇੱਕ "ਕਰੰਟ ਆਰਗ" ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। UI ਵਿੱਚ ਇਸਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ ਅਤੇ ਹਰ ਕਾਰਵਾਈ ਨੂੰ ਉਸਦੇ ਅੰਦਰ ਸਕੋਪ ਕਰੋ।

ਡਿਏਕਟੀਵੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਡਿਲੀਟ ਤੋਂ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ। ਇਹ ਤੁਰੰਤ ਪਹੁੰਚ ਹਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪਿਛਲੇ ਕਾਰਜਾਂ ਨੂੰ ਆਡੀਟ ਕਰਨ ਯੋਗ ਰੱਖਦਾ ਹੈ۔

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਜਾਲਾਂ ਜੋ ਬਚਕੇ ਰਹਿਨ

ਜ਼ਿਆਦਾਤਰ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਨਿਯਮਾਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਜਾਂਦੇ ਹਨ। ਬੁਨਿਆਦੀ ਗੱਲਾਂ (ਟੇਨੈਂਟ ਬਾਊਂਡਰੀ, ਮਲਕੀਅਤ, ਸਕੋਪ) ਦੀ ਰੱਖਿਆ ਕਰੋ ਅਤੇ ਹੋਰ ਸਾਰਾ ਕੁਝ ਵੇਰਵਾ ਸਮਝੋ।

ਰੋਲ ਵਿਆਪਕਤਾ (Role explosion) ਸਭ ਤੋਂ ਆਮ ਝਾਂਪ ਹੈ۔ ਇੱਕ ਐਜ ਕੇਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਨਵਾਂ ਰੋਲ ਬਣਾਉਂਦੇ ਹੋ ਬਜਾਏ ਕਿ ਇੱਕ ਸਪਸ਼ਟ ਅਧਿਕਾਰ ਜਾਂ ਸਕੋਪ ਹੋਵੇ। ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ, ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ "Manager Plus" ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਦੀ ਵਾਰ-ਵਾਰ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਉਸਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਅਧਿਕਾਰ ਬਣਾਉ। ਜੇ ਬਹੁਤ ਘੱਟ ਵਰਤੋਂ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਅਸਥਾਈ ਗ੍ਰਾਂਟ ਨਾਲ ਹੱਲ ਕਰੋ ਜੋ ਮਿਆਦ ਕੇ ਬਾਅਦ ਖਤਮ ਹੋ ਜਾਏ।

ਅਧਿਕਾਰ ਡ੍ਰਿਫਟ (Permission drift) ਚੁਪਚਾਪ ਤੇ ਬਦਤਰ ਹੈ। ਕੋਈ ਇੱਕ ਛੋਟੀ ਛੋਟੀ ਛੂਟ ਜੋੜਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਅਪਡੇਟ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਸਾਲ ਬਾਅਦ, ਲਿਖਤੀ ਨਿਯਮ ਅਤੇ ਅਸਲ ਸਿਸਟਮ ਵਿੱਚ ਵੱਖਰਾਫ਼ਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਮਾਡਲ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਨਿਮਪਲੀਮੈਂਟ।

ਟੀਮਾਂ ਨੂੰ ਨਕਲੀ ਸੁਰੱਖਿਆ ਬਾਊਂਡਰੀ ਬਣਾਉਣਾ ਲਗਾਤਾਰ ਗਲਤਫਹਮੀ ਪੈਦਾ ਕਰਦਾ ਹੈ۔ ਜੇ ਸਰੋਤ ਇੱਕ ਆਰਗ ਦੇ ਅੰਦਰ ਟੀਮਾਂ ਵਿਚਕਾਰ ਸਾਂਝੇ ਹੋ ਸਕਦੇ ਨੇ, ਤਾਂ ਇਸ ਗੱਲ ਨੂੰ ਸਾਫ਼ ਦੱਸੋ। ਜੇ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਉਸਨੂੰ ਕੋਡ ਵਿੱਚ ਬਿਲਕੁਲ ਲਾਗੂ ਕਰੋ, ਨਾਮਾਂ ਵਿੱਚ ਨਹੀਂ۔

ਸ਼ੁਰੂ ਵਿੱਚ ਪਤਾ ਲੱਗਣ ਵਾਲੇ ਰੈਡ ਫਲੈਗ:

• ਇੱਕ "super admin" ਜੋ ਮੂਲ ਤੌਰ 'ਤੇ ਸਾਰੇ ਗ੍ਰਾਹਕ ਆਰਗਾਂ ਦਾ ਡੇਟਾ ਵੇਖ ਸਕਦਾ ਹੈ
• UI-ਕੇਵਲ ਰੋਕ (ਛੁਪੇ ਬਟਨ) ਬਜਾਏ ਸਰਵਰ-ਸਾਈਡ ਚੈੱਕ ਨਹੀਂ
• API ਕੀਅਾਂ ਅਤੇ ਸਰਵਿਸ ਅਕਾਊਂਟ ਜੋ ਮੈਂਬਰਸ਼ਿਪ ਨਿਯਮਾਂ ਨੂੰ ਬਾਇਪਾਸ ਕਰਦੇ ਹਨ
• ਰੋਲ ਜੋ ਨੌਕਰੀ ਦੇ ਅਹੁਦੇ ਨਾਲ ਤਯਾਰ ਕੀਤੇ ਗਏ ਹਨ, ਕਾਰਵਾਈਆਂ ਨਾਲ ਨਹੀਂ
• ਐਸੇ ਛੂਟ ਜੋ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਸਮਝਾਯਾ ਜਾ ਸਕਦਾ

ਜੇ ਸਹਾਇਤਾ ਨੂੰ ਗਾਹਕ ਦੀ ਮਦਦ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, "ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਮਿੰਟ ਲਈ ਗਲੋਬਲ ਐਡਮਿਨ ਦੇ ਦਿਓ" ਇੱਕ ਟੇਨੈਂਟ ਲੀਕ ਬਣਨ ਦਾ ਸੰਕੇਤ ਹੈ। ਇੱਕ ਆਮ ਦਿਲਚਸਪੀ ਵਾਲਾ ਨਿਯਮ ਇਹ ਹੈ: ਖਾਸ, ਲਾਗ ਰਹੀ ਪਹੁੰਚ ਦਿਓ—ਇੱਕ ਆਰਗ, ਨਿਰਧਾਰਤ ਸਮਾਂ ਖਿੜਕੀ, ਨਿਰਧਾਰਤ ਕਾਰਵਾਈਆਂ।

ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼-ਤੇਜ਼ ਚੈਕ

ਹਰ ਰਿਕਵੇਸਟ ਲਈ ਪਹਿਲਾਂ ਐਕਟਿਵ ਆਰਗ ਨੂੰ resolve ਕਰੋ (subdomain, header, session, ਜਾਂ route ਤੋਂ) ਅਤੇ ਓਹ πράਯਾਸ reject ਕਰੋ ਜੋ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।

ਆਰਗ ਸੰਦਰਭ ਮਿਲਣ ਤੋਂ ਬਾਅਦ, ਚੈੱਕ ਇੱਕ ਸਥਿਰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ: ਪਹਿਲਾਂ ਮੈਂਬਰਸ਼ਿਪ (ਕੀ ਉਹ ਇਸ ਆਰਗ ਦਾ ਮੈਂਬਰ ਹੈ?), ਫਿਰ ਰੋਲ (ਇੱਥੇ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ?), ਫਿਰ ਮਲਕੀਅਤ ਜਾਂ ਸਾਂਝਾ ਕਰਨਾ (ਕੀ ਉਸਨੂੰ ਇਸ ਰਿਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਹੈ?). ਜੇ ਤੁਸੀਂ ਮਲਕੀਅਤ ਦੀ ਜਾਂਚ ਪਹਿਲਾਂ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਗੱਲ ਲੀਕ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਮੌਜੂਦ ਹੈ।

ਅਸਲ ਖਾਤਿਆਂ ਨਾਲ ਕੁਝ end-to-end ਟੈਸਟ ਚਲਾਓ, ਸਿਰਫ ਯੂਨਿਟ ਟੈਸਟ ਹੀ ਨਹੀਂ:

• ਨਵੇਂ ਮੈਂਬਰ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਵੇਖਣ, ਬਣਾਉਣ, ਅਤੇ ਡਾਟਾ export ਕਰਨ ਦੀ
• ਟੀਮ ਲੀਡ ਸਿਰਫ ਆਪਣੀ ਟੀਮ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਪੂਰੇ ਆਰਗ ਦਾ
• ਆਰਗ ਐਡਮਿਨ ਰੋਲ ਬਦਲਦਾ ਹੈ, ਫਿਰ ਸਿਗਨਫਿਕੇਟ ਕਾਰਵਾਈ (delete, export) ਕਰਕੇ ਦਿਖਾਉਂਦਾ ਹੈ
• ਹਟਾਇਆ ਗਿਆ ਉਪਭੋਗੀ ਇੱਕ ਪੁਰਾਣੀ ਟੈਬ ਖੋਲ੍ਹ ਰੱਖ ਕੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ
• ਨਿਮੰਤਰਤ (ਪਰ ਸਵੀਕਾਰ ਨਹੀਂ) ਉਪਭੋਗੀ ਪੁਰਾਣੇ ਨਿਮੰਤਰਣ ਲਿੰਕ ਨਾਲ ਐਕਸੈਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ

ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ (ਰੋਲ ਬਦਲ, ਮੈਂਬਰਸ਼ਿਪ ਹਟਾਉਣਾ, exports, deletes, ਸੈਟਿੰਗ ਅੱਪਡੇਟਸ) ਲਈ ਆਧਾਰਭੂਤ ਆਡੀਟ ਇਵੈਂਟ ਜੋੜੋ। ਪਹਿਲੇ ਦਿਨ ਤੇ 완ਪੂਰਨ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ, ਪਰ ਇਹ ਜਾਣਨਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ "ਕੌਣ, ਕਦੋਂ, ਕੀ ਕੀਤਾ"।

ਡਿਫਾਲਟਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ۔ ਨਵੇਂ ਆਰਗ ਅਤੇ ਨਵੇਂ ਮੈਂਬਰਾਂ ਨੂੰ ਉਹੀ ਘੱਟ ਤੋਂ ਘੱਟ ਪਹੁੰਚ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਸਫਲ ਹੋ ਸਕਣ। ਸਹਾਇਤਾ ਅਤੇ ਸੇਲਜ਼ ਲਈ ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ permission FAQ ਵੀ ਲਾਭਦਾਇਕ ਹੈ, ਉਦਾਹਰਨਾਂ ਨਾਲ ਜਿਵੇਂ "ਕੀ ਟੀਮ ਲੀਡ ਹੋਰ ਟੀਮਾਂ ਦੇਖ ਸਕਦਾ ਹੈ?" ਅਤੇ "ਕਿਸੇ ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਬਾਅਦ ਪਹੁੰਚ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ?"۔

ਉਦਾਹਰਣ: ਇੱਕ ਆਰਗ ਤੋਂ ਸੈਂਕੜਿਆਂ ਤੱਕ ਬਿਨਾਂ ਰੀ-ਡਿਜ਼ਾਈਨ ਦੇ

ਇੱਕ ਛੋਟੇ, ਅਸਲੀ ਸੈੱਟਅਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ ਗਾਹਕ ਕੰਪਨੀ (ਇੱਕ ਆਰਗ) ਦੋ ਟੀਮਾਂ ਨਾਲ, Sales ਅਤੇ Ops. ਸਭ ਇਕ ਵਾਰੀ ਸਾਇਨ-ਇਨ ਕਰਦੇ ਹਨ, ਫਿਰ ਉਹਨਾਂ ਦੀ ਆਰਗ ਚੁਣਦੇ ਹਨ। Sales ਨੂੰ customer records ਅਤੇ quotes ਦੀ ਲੋੜ ਹੈ। Ops ਨੂੰ billing ਅਤੇ ਅੰਦਰੂਨੀ ਸੈਟਿੰਗ ਦੀ ਲੋੜ ਹੈ।

ਸਟੇਜ 1: ਇੱਕ ਆਰਗ, ਦੋ ਟੀਮਾਂ

ਟੀਮਾਂ ਨੂੰ ਗ੍ਰੁੱਪਿੰਗ ਅਤੇ ਵਰਕਫਲੋ ਵਜੋਂ ਰੱਖੋ, ਮੁੱਖ ਪਰਮੀਸ਼ਨ ਸਵਿੱਚ ਵਜੋਂ ਨਹੀਂ। ਉਹ defaults ਅਤੇ ਰੂਟਿੰਗ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਇੱਕੋ-ਮਾਤਰ ਗੇਟ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ।

ਸਟੇਜ 2: ਸਥਿਰ ਰੋਲ, ਪੇਸ਼ਗੋਈ ਸਕੋਪ

ਚੋਣ ਕਰੋ ਇੱਕ ਛੋਟਾ ਰੋਲ ਸੈੱਟ ਅਤੇ ਜਦ ਤੱਕ ਫੀਚਰ ਆਉਂਦੇ ਜਾਂਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖੋ: Admin, Member, Viewer. ਰੋਲ ਇਹ ਪੁੱਛਦਾ ਹੈ "ਤੁਸੀਂ ਇਸ ਆਰਗ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦੇ ਹੋ?" ਸਕੋਪ ਪੁਛਦਾ ਹੈ "ਕਿੱਥੇ ਤੁਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹੋ?"

ਸਟੇਜ 3: ਮਲਕੀਅਤ ਸੋਧਣ ਦੇ ਫੈਸਲੇ ਸੌਖੇ ਬਣਾਉਂਦੀ ਹੈ

ਇਕ ਮਲਕੀਅਤ ਨਿਯਮ ਜੋੜੋ: ਹਰ ਸਰੋਤ ਦਾ ਇਕ ਆਰਗ ਅਤੇ ਇਕ ਮਾਲਕ (ਅਕਸਰ ਬਣਾਣ ਵਾਲਾ) ਹੁੰਦਾ ਹੈ। ਸੋਧ ਉਹਨਾਂ ਲਈ ਆਗਿਆ ਹੈ ਜੇ ਤੁਸੀਂ Admin ਹੋ, ਜਾਂ ਜੇ ਤੁਸੀਂ ਮਾਲਕ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਰੋਲ ਵਿੱਚ "edit own" ਸ਼ਾਮਿਲ ਹੈ۔ ਵੇਖਣਾ ਉਸ ਵੇਲੇ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੇ ਤੁਹਾਡੇ ਰੋਲ ਵਿੱਚ ਉਸ ਸਰੋਤ ਦੇ ਲਈ "view" ਹੈ।

ਉਦਾਹਾਰਣ: ਇੱਕ Sales Member ਇੱਕ quote ਬਣਾਂਦਾ ਹੈ। ਦੂਜਾ Sales Member ਉਸਨੂੰ ਵੇਖ ਸਕਦਾ ਹੈ, ਪਰ ਸੋਧ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਦ ਤੱਕ ਉਹ ਟੀਮ ਨਾਲ ਸਾਂਝਾ ਨਾ ਕੀਤਾ ਜਾਵੇ ਜਾਂ ਦੁਬਾਰਾ ਨਿਯੁਕਤ ਨਾ ਕੀਤਾ ਜਾਵੇ। ਇੱਕ Ops Viewer ਇਸਨੂੰ ਤਦ ਹੀ ਵੇਖ ਸਕੇਗਾ ਜੇ ਤੁਹਾਡੇ ਨਿਯਮ Ops ਨੂੰ Sales ਸਰੋਤ ਵੇਖਣ ਦੀ ਆਗਿਆ ਦੇਂਦੇ ਹਨ।

ਸਟੇਜ 4: 200 ਆਰਗ, ਇੱਕੋ ਨਿਯਮ

ਜਦੋਂ ਤੁਸੀਂ 200 ਗਾਹਕ ਆਰਗ ਆਨਬੋਰਡ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕੋ ਰੋਲ ਅਤੇ ਉਹੀ ਮਲਕੀਅਤ ਨਿਯਮ ਦੁਬਾਰਾ ਵਰਤਦੇ ਹੋ। ਤੁਸੀਂ ਮੈਂਬਰਸ਼ਿਪ ਬਦਲਦੇ ਹੋ, ਨਾ ਕਿ ਮਾਡਲ।

ਸਹਾਇਤਾ ਦੀਆਂ ਬੇਨਤੀਆਂ ਜਿਵੇਂ "ਕੀ ਤੁਸੀਂ X ਨੂੰ ਪਹੁੰਚ ਦੇ ਸਕਦੇ ਹੋ?" ਇੱਕ ਚੈਕਲਿਸਟ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਆਰਗ ਅਤੇ ਸਰੋਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਉਪਭੋਗੀ ਦਾ ਰੋਲ ਉਸ ਆਰਗ ਵਿੱਚ ਚੈੱਕ ਕਰੋ, ਮਲਕੀਅਤ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਰੋਲ ਬਦਲੋ ਜਾਂ ਸਰੋਤ ਸਾਂਝਾ ਕਰੋ۔ ਇੱਕ-ਵਾਰੀ ਛੂਟਾਂ ਤੋਂ ਬਚੋ ਅਤੇ ਇੱਕ ਆਡੀਟ ਨੋਟ ਛੱਡੋ۔

ਅਗਲੇ ਕਦਮ: ਲਾਗੂ ਕਰੋ, ਟੈਸਟ ਕਰੋ, ਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਦੁਰੁਸਤ ਕਰੋ

ਆਪਣੇ ਇਕ-ਪੰਨੇ ਮਾਡਲ ਨੂੰ ਇੱਕ ਠੇਕਾ ਸਮਝੋ۔ ਸਿਰਫ ਉਹ ਨਿਯਮ ਲਾਗੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਹਰ API ਕਾਲ ਅਤੇ ਹਰ UI ਸਕਰੀਨ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਨਹੀਂ ਤਾਂ ਅਧਿਕਾਰ "ਇਹ ਤੇ ਨਿਰਭਰ" ਵਿੱਚ ਡਿੱਗ ਜਾਂਦੇ ਹਨ।

ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕੁਝ ਰੋਲ, ਸਪਸ਼ਟ ਸਕੋਪ, ਅਤੇ ਸਧਾਰਣ ਮਲਕੀਅਤ। ਜਦੋ ਕੋਈ ਨਵਾਂ ਬੇਨਤੀ ਆਵੇ ("ਕੀ ਅਸੀਂ Editor-Manager ਰੋਲ ਜੋੜ ਸਕਦੇ ਹਾਂ?"), ਪਹਿਲਾਂ ਮਲਕੀਅਤ ਜਾਂ ਸਕੋਪ ਕਸੋਤ ਕਰੋ۔ ਨਵੇਂ ਰੋਲ ਘੱਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਹਰ ਨਵੇਂ ਸਰੋਤ ਲਈ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸੰਗਠਿਤ ਰੱਖੋ:

• org_id ਸਟੋਰ ਕਰਦਾ ਹੋਵੇ (ਅਤੇ ਜੇ ਲਾਗੂ ਹੋਵੇ ਤਾਂ team_id)
• ਇੱਕ ਵਿਜ਼ੀਬਿਲਿਟੀ ਨਿਯਮ ਹੋਵੇ (private, team, org)
• ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਆਡੀਟ ਇਵੈਂਟ ਰਿਕਾਰਡ ਹੋਣ
• ਹਰ ਕ੍ਵੈਰੀ ਵਿੱਚ ਸਕੋਪ ਦੁਆਰਾ ਫਿਲਟਰ ਕੀਤਾ ਜਾਵੇ (UI ਤੱਕ ਹੀ ਨਹੀਂ)
• ਡਿਫਾਲਟ ਆਗੇ ਦੇਖਣਯੋਗ ਹੋਣ ਕਿ ਬਣਾਉਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ

ਛੋਟੇ ਫਲੋਜ਼ ਨੂੰ ਪੋਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਫਲੋਜ਼ ਟੈਸਟ ਕਰੋ: ਨਿਮੰਤਰਣ, ਆਰਗ ਸਵਿੱਚ ਕਰਨਾ, ਐਡਮਿਨ ਪੇਜ, ਅਤੇ ਦੈਹਾਗ ਹੋਣ ਦੌਰਾਨ ਕਿਸੇ ਦੇ ਪਹੁੰਚ ਖਤਮ ਹੋਣ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ۔

ਜੇ ਤੁਸੀਂ ਇੱਕ chat-based app builder ਨਾਲ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਸਾਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਲਿਖਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਨਾਲ ਰੱਖੋ। Koder.ai (koder.ai) 'ਤੇ Planning Mode ਨਾਲ snapshots ਅਤੇ rollback ਉਹ ਦ੍ਰਿਸ਼ਯ ਹਨ ਜੋ ਇਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਟ੍ਰਾਇਅਲ ਕਰਨ ਅਤੇ ਇਹ ਪੱਕਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਨਿਯਮ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਇੱਕੋ ਤਰ੍ਹਾਂ ਵਰਤਦੇ ਹਨ।