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

ਅਧਿਕਾਰਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ ਤੇ ਛੋਟੀ ਪਰੇਸ਼ਾਨੀਆਂ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਟਿਕਟ ਆਉਂਦੀ ਹੈ: "ਮੈਂ ਐਡਮਿਨ ਹਾਂ ਪਰ ਮੈਂ ਇਨਵੌਇਸ ਨਹੀਂ ਦੇਖ ਸਕਦਾ۔" ਹੋਰ: "ਮੇਰਾ ਸਾਥੀ ਸੈਟਿੰਗਸ ਕਿਉਂ ਸੋਧ ਸਕਦਾ ਹੈ؟" ਲੋਕ ਕਲਿੱਕ ਕਰਦੇ ਨੇ, ਅਨੁਮਾਨ ਲਾਉਂਦੇ ਨੇ, ਤੇ ਕਈ ਵਾਰੀ ਇੱਕ ਹੀ "owner" ਲੌਗਿਨ ਸਾਂਝਾ ਕਰ ਲੈਂਦੇ ਨੇ ਕਿਉਂਕਿ ਇਹ ਸੈਟਿੰਗ ਸੈਟ ਕਰਵਾਉਣ ਨਾਲੋਂ ਤੇਜ਼ ਲੱਗਦਾ ਹੈ।
ਫਿਰ ਵਰਕਅਰਾਊਂਡਾਂ ਇਕੱਠੇ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਟੀਮਾਂ ਅਜਿਹੇ ਰੋਲ ਬਣਾਉਂਦੀਆਂ ਨੇ ਜਿਵੇਂ "Admin 2" ਜਾਂ "Manager (no delete)"۔ ਇੰਜੀਨੀਅਰਾਂ ਇੱਕ-ਵਾਰੀ ਜਾਂਚਾਂ ਜੋੜਦੇ ਹਨ ਜਿਵੇਂ "ਜੇ ਉਪਭੋਗੀ Sales ਵਿੱਚ ਹੈ ਤਾਂ export ਦੀ ਆਗਿਆ ਦਿਓ" ਕਿਉਂਕਿ ਇਹ ਅੱਜ ਦੀ ਗ਼ਲਤੀ ਠੀਕ ਕਰਦਾ ਹੈ۔ ਇਕ ਮਹੀਨੇ ਬਾਅਦ, ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕਿਹੜੇ ਨਿਯਮ ਜਾਣ-ਬੁਝ ਕੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਦੋਸ਼ਵਸ਼ ਘਟਕੇ ਆ ਗਏ ਨੇ۔
ਇਹ ਮਾਲਕੂਲ ਹੋ ਜਾਂਦਾ ਜਦੋਂ ਤੁਸੀਂ ਹੋਰ ਗਾਹਕ ਜੋੜਦੇ ਹੋ। ਇੱਕ ਨਿਯਮ ਜੋ ਇੱਕ ਕੰਪਨੀ ਲਈ ਠੀਕ ਲੱਗ ਰਿਹਾ ਸੀ ("admins ਸਾਰੇ ਡੇਟਾ ਦੇਖ ਸਕਦੇ ਨੇ") ਉਹ ਸੈੱਟਅਪ ਸੈਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸੈਂਕੜਿਆਂ ਆਰਗ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਉਮੀਦਾਂ ਵੱਖ-ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ۔ ਕੋਈ ਗਾਹਕ ਵਿਭਾਗਾਂ ਵਿੱਚ ਸਖ਼ਤ ਵੱਖਰਾ ਚਾਹੁੰਦਾ ਹੈ। ਹੋਰ ਕੋਈ ਸਾਂਝਾ ਵਰਕਸਪੇਸ ਚਾਹੁੰਦਾ ਹੈ। ਕੁਝ ਇਕ ਠੇਕਾਦਾਰ ਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਤੱਕ ਹੀ ਪਹੁੰਚ ਦੈਣਾ ਚਾਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਮਾਡਲ ਸਪਸ਼ਟ ਨਹੀਂ, ਤਾਂ ਹਰ ਨਵਾਂ ਗਾਹਕ ਇਕ ਨਵਾਂ Ausnahme ਹੋ ਜਾਉਂਦਾ ਹੈ।
ਹدف ਸਧਾਰਨ ਹੈ: ਅਣੁਮਾਨਕ ਅਤੇ ਪੇਸ਼ਗੋਈ ਯੋਗ ਅਕਸੇਸ ਨਿਯਮ ਜੋ ਤੁਸੀਂ ਇਕ ਮਿੰਟ ਵਿੱਚ ਸਮਝਾ ਸਕੋ۔ ਉਦਾਹਰਣ: "ਤੁਹਾਡੀ ਸੰਗਠਨ ਡੇਟਾ ਦੀ ਮਾਲਿਕ ਹੈ۔ ਟੀਮਾਂ ਲੋਕਾਂ ਨੂੰ ਗ੍ਰੁੱਪ ਕਰਦੀਆਂ ਹਨ۔ ਰੋਲ ਕਾਰਵਾਈਆਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ۔ ਸਰੋਤ ਇੱਕ ਸੰਗਠਨ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਦੇ-ਕਦੇ ਇੱਕ ਟੀਮ ਨਾਲ। ਸਾਂਝੇ ਕਰਨਾ ਕੁਝ ਫ਼ੈਲਟਸ ਦੇ ਅਨੁਸਾਰ ਹੁੰਦਾ ਹੈ۔" ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਫ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਉਸਨੂੰ ਬਣਾਉਣਾ, ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ۔
ਇੱਕ ਵਾਅਦਾ ਜੋ ਰੱਖਣ ਲਾਇਕ ਹੈ: ਘੱਟ ਰੋਲ, ਸਪਸ਼ਟ ਮਲਕੀਅਤ, ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ। ਸੱਚੇ ਕੰਮ-ਨਿਭਾਉਂਦੇ ਰੋਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹਰ ਸਰੋਤ ਲਈ ਮਲਕੀਅਤ ਆਸਾਨੀ ਨਾਲ ਦੇਖਣਯੋਗ ਬਣਾਓ, ਅਤੇ ਸਬ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ۔ ਫਿਰ ਇਰਾਦੇ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿਓ, ਅਖ਼ਤਿਆਰੀ ਤੌਰ ’ਤੇ ਨਹੀਂ۔
ਜੇ ਤੁਹਾਡੀ ਐਪ ਇੱਕ ਤੋਂ ਵੱਧ ਗਾਹਕਾਂ ਨੂੰ ਸੇਵਾ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਨਸਕ ਨਕਸ਼ਾ ਸਹੀ ਰੱਖੋ। ਬਹੁ-ਟੇਨੈਂਟ SaaS ਅਧਿਕਾਰਾਂ ਵਿੱਚ ਅਧਿਕਤਮ ਗਲਤੀ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੇ ਪਰਸਾਰ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਜਿੱਥੇ ਇੱਕੋ ਸ਼ਬਦ ਉਤਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਤਲਬ ਰੱਖਦਾ ਹੈ۔
ਆਪਣਾ ਟੇਨੈਂਟ ਬਾਉਂਡਰੀ ਲਈ ਇੱਕ ਮਤਲਬ ਚੁਣੋ ਅਤੇ ਉਸ ਤੇ ਟਿਕੇ ਰਹੋ। ਬਹੁਤੀਆਂ ਉਤਪਾਦ "organization" ਨੂੰ ਟੇਨੈਂਟ ਵਜੋਂ ਵਰਤਦੇ ਹਨ: ਸਾਰਾ ਡੇਟਾ ਇੱਕ ਆਰਗ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਉਸ ਲਕੀਰ ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰਦਾ ਜਦ ਤੱਕ ਤੁਸੀਂ ਖਾਸ ਤੌਰ ’ਤੇ ਸਾਂਝਾ ਕਰਨ ਦੀ ਬਣਾਣੀ ਨਹੀਂ ਕਰਦੇ।
ਇੱਕ ਸਧਾਰਣ ਸ਼ਬਦ-ਭੰਡਾਰ ਜੋ ਵੱਧਣ ਦੇ ਨਾਲ ਵੀ ਸਪਸ਼ਟ ਰਹੇ:
"ਇੱਕ ਵਿਅਕਤੀ, ਬਹੁਤ ਸਾਰੀਆਂ ਆਰਗਾਂ" ਆਮ ਹੈ। ਇਕ ਸਲਾਹਕਾਰ ਤਿੰਨ ਗਾਹਕ-aarਗਾਂ ਦਾ ਮੈਂਬਰ ਹੋ ਸਕਦਾ ਹੈ, ਹਰ ਇੱਕ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਰੋਲ। ਇਸੀ ਲਈ "ਉਪਭੋਗੀ" ਅਤੇ "ਮੈਂਬਰਸ਼ਿਪ" ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਤੁਹਾਡੀ ਜਾਂਚ ਆਮ ਤੌਰ ਤੇ ਮੈਂਬਰਸ਼ਿਪ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀ ਹੈ, ਨ ਕਿ ਸਿਰਫ ਉਪਭੋਗੀ 'ਤੇ।
ਜਦ ਟੀਮਾਂ ਅਸਲ ਗ੍ਰੁੱਪਿੰਗ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਜਿਵੇਂ "Support" ਜਾਂ "Finance", ਤਾਂ ਉਹ ਮਦਦਗਾਰ ਹੁੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਉਹ ਦੂਜੇ ਅਧਿਕਾਰ ਪ੍ਰਣਾਲੀ ਬਣ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਓਹ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ۔ ਇੱਕ ਉਪਯੋਗੀ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਟੀਮ ਨੂੰ ਇਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਖਾਸ ਫੀਚਰ ਨਿਯਮ ਦਾ ਜ਼ਿਕਰ ਕੀਤੇ।
ਉਦਾਹਰਣ: ਮਾਰੀਆ ਇਕ ਵਾਰੀ ਲੌਗ ਇਨ ਕਰਦੀ ਹੈ, ਫਿਰ Org A ਅਤੇ Org B ਵਿਚੋਂ ਸਵਿੱਚ ਕਰਦੀ ਹੈ। Org A ਵਿੱਚ ਉਹ Finance ਵਿੱਚ ਹੈ ਅਤੇ ਇਨਵੌਇਸ ਵੇਖ ਸਕਦੀ ਹੈ। Org B ਵਿੱਚ ਉਹ Viewer ਹੈ ਅਤੇ ਸਿਰਫ ਪ੍ਰੋਜੈਕਟ ਪੜ੍ਹ ਸਕਦੀ ਹੈ। ਇਕੋ ਉਪਭੋਗੀ, ਵੱਖ-ਵੱਖ ਮੈਂਬਰਸ਼ਿਪ, ਸਪਸ਼ਟ ਬਾਊਂਡਰੀ।
ਬਹੁ-ਟੇਨੈਂਟ SaaS ਅਧਿਕਾਰ ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦੇ ਹੋ:
RBAC (role-based access control) ਦਾ ਮਤਲਬ ਹੈ: ਤੁਸੀਂ ਇਕ ਉਪਭੋਗੀ ਨੂੰ ਰੋਲ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਉਹ ਰੋਲ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਾਰਵਾਈਆਂ ਦਿੰਦਾ ਹੈ۔ ਰੋਲ ਨਾਂ ਜਿੰਮੇਵਾਰੀ ਨੂੰ ਦਰਸਾਉਣੇ ਚਾਹੀਦੇ ਹਨ, ਹਾਲਤ ਨੂੰ ਨਹੀਂ۔ "Billing Admin" ਸਪੱਸ਼ਟ ਹੈ। "Power User" ਅਕਸਰ ਬਹਿਸ ਪੈਦਾ ਕਰਦਾ ਹੈ۔
ਅਧਿਕਾਰਾਂ ਨੂੰ ਕਿਰਿਆ-ਪਦ ਵਰਗੇ ਸੌਖੇ ਰੱਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੂਰੇ ਉਤਪਾਦ ਵਿੱਚ ਸਤਤ ਰੱਖੋ:
ਫਿਰ ਸਕੋਪ ਜੋੜੋ ਤਾਂ ਜੋ ਇੱਕੋ ਕਿਰਿਆ ਵੱਖ-ਵੱਖ ਸਥਾਨਾਂ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕੇ। ਇਹੀ ਤਰੀਕਾ ਤੁਹਾਨੂੰ 20 ਥੋੜ੍ਹੇ ਬਦਲ ਰੋਲਾਂ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ۔
ਆਮ ਸਕੋਪ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਰੋਲ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ "Project Editor" ਅਤੇ "Project Editor (Own)" ਵਰਗੇ ਰੋਲ ਬਣਾਉਣ ਲੱਗੋ, ਤਾਂ ਇਹ ਅਕਸਰ ਸਕੋਪ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਰੋਲ ਦੀ ਨਹੀਂ।
ਉਦਾਹਰਣ: ਇੱਕ CRM ਵਿੱਚ, "Sales Rep" ਨੂੰ ਸੌਂਪੋ ਕਿ ਉਹ ਡੀਲ ਬਣਾਏ ਅਤੇ ਸੋਧੇ, ਪਰ ਸਕੋਪ "own items" ਤੱਕ ਸੀਮਿਤ ਕਰੋ। "Sales Manager" ਨੂੰ ਉਹੀ ਕਿਰਿਆਵਾਂ ਦਿਓ ਪਰ "team-only" ਜਾਂ "org-wide" ਸਕੋਪ ਦੇ ਨਾਲ। ਤੁਹਾਨੂੰ ਘੱਟ ਰੋਲ, ਸਪਸ਼ਟ ਨਿਯਮ ਅਤੇ ਘੱਟ ਹੈਰਾਨੀ ਮਿਲੇਗੀ ਜਦੋਂ ਕੋਈ ਟੀਮ ਬਦਲਦੀ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫਾਲਟ ਇਹ ਹੈ: ਰੋਲ ਕਿਰਿਆਵਾਂ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਮਲਕੀਅਤ (ਜਾਂ ਨਿਯੁਕਤੀ) ਇਹ ਨਿਯਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਕੰਮ ਕਰੇਗੀ۔
ਜੇ ਤੁਹਾਡਾ ਮਾਡਲ ਇੱਕ ਗਾਹਕ ਲਈ ਚੰਗਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਪਰ ਦੱਸ ਤੱਕ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ "ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ" ਨੂੰ "ਕੌਣ ਕਰ ਸਕਦਾ ਹੈ" ਅਤੇ "ਕੌਣ ਮਲਿਕ ਹੈ" ਨਾਲ ਮਿਲਾ ਦਿੱਤਾ ਹੈ۔ ਇਹ ਤਿੰਨ ਗੱਲਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰੇਡੀਕਟੇਬਲ ਰਹੇਗਾ।
ਇੱਕ ਐਸਾ ਨਿਯਮ-ਸੈੱਟ ਜੋ ਸਕੇਲ ਹੁੰਦਾ ਹੈ:
ਉਦਾਹਰਣ: ਸੈਮ Org A ਅਤੇ Org B ਦਾ ਮੈਂਬਰ ਹੈ۔ Org A ਵਿੱਚ ਸੈਮ Member ਹੈ ਅਤੇ ਉਹ ਆਪਣੀਆਂ ਰਿਪੋਰਟਾਂ ਬਣਾਕੇ ਸੋਧ ਸਕਦਾ ਹੈ ਪਰ ਬਿਲਿੰਗ ਨਹੀਂ ਬਦਲ ਸਕਦਾ۔ Org B ਵਿੱਚ ਸੈਮ Billing Manager ਹੈ ਅਤੇ ਉਹ ਭੁਗਤਾਨ ਤਰੀਕੇ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਨਵੌਇਸ ਡਾਉਨਲੋਡ ਕਰ ਸਕਦਾ ਹੈ، ਪਰ ਫਿਰ ਵੀ ਉਹ ਪ੍ਰਾਈਵੇਟ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਜਦ ਤੱਕ ਉਸਦੀ ਮੈਂਬਰਸ਼ਿਪ ਉਸ ਖੇਤਰ ਨੂੰ ਸ਼ਾਮਿਲ ਨਹੀਂ ਕਰਦੀ।
ਇਸ ਨਾਲ ਵੱਧਣਾ ਅਚਾਨਕ ਬੋoring ਬਣ ਜਾਂਦਾ ਹੈ—ਵਧਾਉਣਾ ਸਿਰਫ ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ ਰੋਲਾਂ ਜੋੜਨਾ ਹੁੰਦਾ ਹੈ। ਮੁੱਖ ਨਿਯਮ ਇੱਕੋ ਹੀ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਸਫ਼ਾ ਲਿਖੋ ਜੋ ਕੋਈ ਸਾਥੀ ਦੋ ਮਿੰਟ ਵਿੱਚ ਪੜ੍ਹ ਸਕੇ। ਜੇ ਤੁਸੀਂ ਕੋਡ ਖੋਲ੍ਹਣ ਤੋਂ ਬਿਨਾਂ ਅਧਿਕਾਰ ਸਮਝਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਧੀਆ ਹਾਲਤ ਵਿੱਚ ਹੋ۔
ਭਾਗਾਂ ਨੂੰ ਜਾਨਬੂਝ ਕਰਕੇ ਛੋਟਾ ਰੱਖੋ:
ਰੋਲ ਐਕਸਪਲੋਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ ਸਕੋਪ ਵਰਤੋਂ। ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦਾਂ ਨੂੰ ਕੇਵਲ ਤਿੰਨ ਸਕੋਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: own, team, org.
| Role | View | Edit | Invite users | Billing | Scope note |
|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | Org-wide, ਮਲਕੀਅਤ ਦੇ ਹਵਾਲੇ ਟਰਾਂਸਫਰ ਕਰ ਸਕਦਾ ਹੈ |
| Admin | Yes | Yes | Yes | No/Yes | Org-wide, ਮਲਕੀਅਤ ਬਦਲਣ ਨਹੀਂ ਕਰ ਸਕਦਾ |
| Member | Yes | Limited | No | No | Own + team (ਜਿੱਥੇ ਨਿਯੁਕਤ) |
| Viewer | Yes | No | No | No | Read-only ਨਿਰਧਾਰਤ ਸਕోਪ ਵਿੱਚ |
ਸੈਨਟੀ ਚੈੱਕ: ਇਸ ਪੰਨੇ ਨੂੰ ਕਿਸੇ ਗੈਰ-ਟੈਕਨੀਕੀ ਸਾਥੀ ਨੂੰ ਦਿਖਾਉ ਅਤੇ ਪੁੱਛੋ, "ਕੀ Support member Sales ਰਿਪੋਰਟ ਸੋਧ ਸਕਦਾ ਹੈ?" ਜੇ ਉਹ ਹਿਚਕਿਚਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਸਕੋਪ ਜਾਂ ਟੀਮ ਦੀ ਪਰਿਭਾਸ਼ਾ ਸਪਸ਼ਟ ਨਹੀਂ।
ਅਧਿਕਾਰਾਂ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਣ ਲਈ, ਹਰ ਸਰੋਤ ਦੀ ਮਲਕੀਅਤ ਨਿਰਧਾਰਤ ਕਰੋ, ਫਿਰ ਸਾਂਝੇ ਕਰਨ ਦੇ ਵਿਕਲਪ ਸੀਮਿਤ ਰੱਖੋ۔
ਜ਼ਿਆਦਾਤਰ ਸਰੋਤਾਂ ਨੂੰ ਆਰਗ-ਮੈਲਕਾਨਾ ਬਨਾਓ। ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਨੀ ਦੀਆਂ ਧਾਰਣਾਵਾਂ ਵਿੱਚ ਸੋਚਦੇ ਹਨ: ਇਨਵੌਇਸ, ਪ੍ਰੋਜੈਕਟ, ਸੰਪਰਕ, ਟਿਕਟ, ਆਟੋਮੇਸ਼ਨ ਸੰਗਠਨ ਦੇ ਮਾਲਕ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਵਿਅਕਤੀਗਤ।
ਟੀਮਾਂ ਫਿਰ ਵੀ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਟੀਮ ਨੂੰ ਇੱਕ ਵਰਕਫਲੋ ਲੇਬਲ ਵਜੋਂ ਪ੍ਰਤੱਖ ਕਰੋ ਜੋ ਰੂਟਿੰਗ ਅਤੇ ਡਿਫਾਲਟ ਵਿਜ਼ੀਬਿਲਿਟੀ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਹਾਰਡ ਸੁਰੱਖਿਆ ਲਾਜਿਕ ਵਜੋਂ۔ ਟੀਮ ਟੈਗ ਫਿਲਟਰ, ਡੈਸ਼ਬੋਰਡ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਜਾਂ ਕਿਊਜ਼ ਚਲਾਉਣ ਵਾਸਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਦ ਕਿ ਅੈਕਸੈਸ ਫਿਰ ਵੀ ਰੋਲ ਅਤੇ ਸਕੋਪ ਤੋਂ ਆਉਂਦਾ ਹੈ।
ਉਪਭੋਗੀ-ਮਾਲਕ ਸਰੋਤ ਅਪਵਾਦ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਸਿਰਫ ਐਸੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਜੋ ਸੱਚਮੁੱਚ ਨਿੱਜੀ ਹਨ: ਡਰਾਫਟ, ਨਿੱਜੀ ਨੋਟਸ, ਸੇਵ ਕੀਤੇ ਵਿਊਅਜ਼, API ਟੋਕਨ, ਜਾਂ ਨਿੱਜੀ ਸੈਟਿੰਗ। ਜੇ ਕੋਈ ਉਪਭੋਗੀ ਛੱਡ ਕੇ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਕਰਨਾ ਹੈ: ਮਿਟਾਉਣਾ, ਟਰਾਂਸਫਰ ਕਰਨਾ, ਜਾਂ ਨਿੱਜੀ ਰੱਖਣਾ।
ਸਾਂਝੇ ਕਰਨ ਦੇ ਕੁਝ ਛੋਟੇ ਨਿਯਮ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੇ ਹਨ:
ਜਦੋਂ ਕੋਈ ਕਹਿੰਦਾ ਹੈ "ਮੈਨੂੰ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ," ਤਾਂ ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਹੜੇ ਪੱਧਰ 'ਤੇ ਹੈ: ਉਹਨਾਂ ਦੀ ਨਿੱਜੀ ਵਸਤੂ, ਉਹਨਾਂ ਦੀ ਟੀਮ ਦਾ ਕੰਮ, ਜਾਂ ਪੂਰੀ ਆਰਗ। ਜੇ ਇਹ ਤਿੰਨ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਅਕਸਰ ਇਹ ਸੂਚਨ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਕੋਪ ਸਪਸ਼ਟ ਨਹੀਂ, ਨਾ ਕਿ ਤੁਹਾਨੂੰ ਨਵਾਂ ਸਾਂਝਾ ਕਰਨ ਦਾ ਢੰਗ ਚਾਹੀਦਾ ਹੈ۔
ਉਦਾਹਰਨ: ਇੱਕ ਸਪੋਰਟ ਟਿਕਟ ਆਰਗ-ਮਾਲਕ ਹੋ ਸਕਦੀ ਹੈ (ਤਾਂ ਜੋ ਮੈਨੇਜਰ ਸਾਰੇ ਟਿਕਟਾਂ 'ਤੇ ਰਿਪੋਰਟ ਕਰ ਸਕਣ), Support ਨੂੰ ਟੀਮ-ਟੈਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਸੀਧੇ ਕਿਊ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਲਈ), ਅਤੇ Jordan ਨੂੰ ਅਸਾਈਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਜੋ ਜਵਾਬਦੇਹੀ ਦਿਖਾਉਂਦਾ ਹੈ)। ਅਸਾਈਨਮੈਂਟ ਹੋਰ ਆਗਿਆਵਾਂ ਵਾਲੇ ਰੋਲਾਂ ਨੂੰ ਵੇਖਣ ਤੋਂ ਰੋਕਣੀ ਚਾਹੀਦੀ ਨਹੀਂ।
ਅਧਿਕਾਰ ਅਕਸਰ "ਲੋਕ ਘਟਨਾਵਾਂ" ਦੌਰਾਨ ਟੁਟਦੇ ਹਨ: ਕਿਸੇ ਨੂੰ ਨਿਯੋਤਾ ਭੇਜਣਾ, ਉਹਨਾਂ ਨੂੰ ਟੀਮਾਂ ਵਿਚ ਘੁੰਮਾਉਣਾ, ਜਾਂ ਪਹੁੰਚ ਹਟਾਉਣਾ। ਇਹ ਫਲੋ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਮਾਡਲ ਅਣੁਮਾਨਕ ਰਹੇਗਾ ਜਾਂ ਨਹੀਂ۔
ਇੱਕ ਨਿਮੰਤਰਣ ਨੂੰ ਮੈਂਬਰਸ਼ਿਪ ਬਣਾਉਣ ਦੀ ਬੇਨਤੀ ਵਜੋਂ ਵਰਤੋ, ਆਪਣੇ ਆਪ ਪਹੁੰਚ ਨਹੀਂ। ਨਿਮੰਜਰ ਨੂੰ ਆਰਗ, ਟੀਮ (ঐচ্ছਿਕ), ਅਤੇ ਰੋਲ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਿ ਸਵੀਕਾਰ ਕਰਨ ਤੇ ਮਿਲੇਗਾ۔
ਆਪਣਾ ਨਿਯਮ ਕਸੇ ਰੱਖੋ:
ਅਸਥਾਈ ਪਹੁੰਚ ਇੱਥੇ ਫਿੱਟ ਹੁੰਦੀ ਹੈ ਵੀ۔ ਇਕ "ਟੈਮਪ ਯੂਜ਼ਰ" ਰੋਲ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਰੋਲ ਗ੍ਰਾਂਟ ਨੂੰ ਇੱਕ ਅਖੀਰ ਦੀ ਤਾਰੀਖ ਦੇਣ ਦੀ ਆਗਿਆ ਦਿਓ। ਜਦੋਂ ਉਹ ਆ ਜਾਂਦੀ ਹੈ, ਪਹੁੰਚ ਆਪਣੇ-ਆਪ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਏਗੀ ਅਤੇ ਆਡੀਟ ਟਰੇਲ ਸਾਫ਼ ਰਹੇਗੀ।
ਜਦੋਂ ਕੋਈ ਆਰਗ ਛੱਡਦਾ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਦੇ ਸਰੋਤਾਂ ਨਾਲ ਫੈਸਲਾ ਕਰਨਾ ਅੰਦਾਜ਼ਾ ਨਾ ਕਰੋ। ਜੇ ਤੁਹਾਡਾ ਨਿਯਮ "ਸਰੋਤ ਆਰਗ-ਮਾਲਕ ਹਨ," ਤਾਂ ਇਸ ਤੇ ਟਿਕੋ। ਵਿਅਕਤੀ ਨੂੰ ਇਤਿਹਾਸ ਲਈ ਬਣਾਇਆ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਪਰ ਆਰਗ ਮਾਲਕ ਰਹੇਗਾ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਉਪਭੋਗੀ-ਮਾਲਕ ਸਰੋਤ ਹਨ, ਤਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਆਈਟਮਾਂ (ਪ੍ਰੋਜੈਕਟ, ਦਸਤਾਵੇਜ਼, API ਕੀ) ਲਈ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟਰਾਂਸਫਰ ਲਾਜ਼ਮੀ ਕਰੋ۔
ਇੱਕ ਲਾਗਿਨ ਬਹੁਤ ਸਾਰੀਆਂ ਆਰਗਾਂ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ, ਪਰ ਐਪ ਨੂੰ ਹਮੇਸ਼ਾ ਇੱਕ "ਕਰੰਟ ਆਰਗ" ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। UI ਵਿੱਚ ਇਸਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ ਅਤੇ ਹਰ ਕਾਰਵਾਈ ਨੂੰ ਉਸਦੇ ਅੰਦਰ ਸਕੋਪ ਕਰੋ।
ਡਿਏਕਟੀਵੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਡਿਲੀਟ ਤੋਂ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ। ਇਹ ਤੁਰੰਤ ਪਹੁੰਚ ਹਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪਿਛਲੇ ਕਾਰਜਾਂ ਨੂੰ ਆਡੀਟ ਕਰਨ ਯੋਗ ਰੱਖਦਾ ਹੈ۔
ਜ਼ਿਆਦਾਤਰ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਇਸ ਲਈ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਨਿਯਮਾਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਜਾਂਦੇ ਹਨ। ਬੁਨਿਆਦੀ ਗੱਲਾਂ (ਟੇਨੈਂਟ ਬਾਊਂਡਰੀ, ਮਲਕੀਅਤ, ਸਕੋਪ) ਦੀ ਰੱਖਿਆ ਕਰੋ ਅਤੇ ਹੋਰ ਸਾਰਾ ਕੁਝ ਵੇਰਵਾ ਸਮਝੋ।
ਰੋਲ ਵਿਆਪਕਤਾ (Role explosion) ਸਭ ਤੋਂ ਆਮ ਝਾਂਪ ਹੈ۔ ਇੱਕ ਐਜ ਕੇਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਨਵਾਂ ਰੋਲ ਬਣਾਉਂਦੇ ਹੋ ਬਜਾਏ ਕਿ ਇੱਕ ਸਪਸ਼ਟ ਅਧਿਕਾਰ ਜਾਂ ਸਕੋਪ ਹੋਵੇ। ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ, ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ "Manager Plus" ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਦੀ ਵਾਰ-ਵਾਰ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਉਸਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਅਧਿਕਾਰ ਬਣਾਉ। ਜੇ ਬਹੁਤ ਘੱਟ ਵਰਤੋਂ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਅਸਥਾਈ ਗ੍ਰਾਂਟ ਨਾਲ ਹੱਲ ਕਰੋ ਜੋ ਮਿਆਦ ਕੇ ਬਾਅਦ ਖਤਮ ਹੋ ਜਾਏ।
ਅਧਿਕਾਰ ਡ੍ਰਿਫਟ (Permission drift) ਚੁਪਚਾਪ ਤੇ ਬਦਤਰ ਹੈ। ਕੋਈ ਇੱਕ ਛੋਟੀ ਛੋਟੀ ਛੂਟ ਜੋੜਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਅਪਡੇਟ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਸਾਲ ਬਾਅਦ, ਲਿਖਤੀ ਨਿਯਮ ਅਤੇ ਅਸਲ ਸਿਸਟਮ ਵਿੱਚ ਵੱਖਰਾਫ਼ਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਮਾਡਲ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਨਿਮਪਲੀਮੈਂਟ।
ਟੀਮਾਂ ਨੂੰ ਨਕਲੀ ਸੁਰੱਖਿਆ ਬਾਊਂਡਰੀ ਬਣਾਉਣਾ ਲਗਾਤਾਰ ਗਲਤਫਹਮੀ ਪੈਦਾ ਕਰਦਾ ਹੈ۔ ਜੇ ਸਰੋਤ ਇੱਕ ਆਰਗ ਦੇ ਅੰਦਰ ਟੀਮਾਂ ਵਿਚਕਾਰ ਸਾਂਝੇ ਹੋ ਸਕਦੇ ਨੇ, ਤਾਂ ਇਸ ਗੱਲ ਨੂੰ ਸਾਫ਼ ਦੱਸੋ। ਜੇ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਉਸਨੂੰ ਕੋਡ ਵਿੱਚ ਬਿਲਕੁਲ ਲਾਗੂ ਕਰੋ, ਨਾਮਾਂ ਵਿੱਚ ਨਹੀਂ۔
ਸ਼ੁਰੂ ਵਿੱਚ ਪਤਾ ਲੱਗਣ ਵਾਲੇ ਰੈਡ ਫਲੈਗ:
ਜੇ ਸਹਾਇਤਾ ਨੂੰ ਗਾਹਕ ਦੀ ਮਦਦ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, "ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਮਿੰਟ ਲਈ ਗਲੋਬਲ ਐਡਮਿਨ ਦੇ ਦਿਓ" ਇੱਕ ਟੇਨੈਂਟ ਲੀਕ ਬਣਨ ਦਾ ਸੰਕੇਤ ਹੈ। ਇੱਕ ਆਮ ਦਿਲਚਸਪੀ ਵਾਲਾ ਨਿਯਮ ਇਹ ਹੈ: ਖਾਸ, ਲਾਗ ਰਹੀ ਪਹੁੰਚ ਦਿਓ—ਇੱਕ ਆਰਗ, ਨਿਰਧਾਰਤ ਸਮਾਂ ਖਿੜਕੀ, ਨਿਰਧਾਰਤ ਕਾਰਵਾਈਆਂ।
ਹਰ ਰਿਕਵੇਸਟ ਲਈ ਪਹਿਲਾਂ ਐਕਟਿਵ ਆਰਗ ਨੂੰ resolve ਕਰੋ (subdomain, header, session, ਜਾਂ route ਤੋਂ) ਅਤੇ ਓਹ πράਯਾਸ reject ਕਰੋ ਜੋ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।
ਆਰਗ ਸੰਦਰਭ ਮਿਲਣ ਤੋਂ ਬਾਅਦ, ਚੈੱਕ ਇੱਕ ਸਥਿਰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ: ਪਹਿਲਾਂ ਮੈਂਬਰਸ਼ਿਪ (ਕੀ ਉਹ ਇਸ ਆਰਗ ਦਾ ਮੈਂਬਰ ਹੈ?), ਫਿਰ ਰੋਲ (ਇੱਥੇ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ?), ਫਿਰ ਮਲਕੀਅਤ ਜਾਂ ਸਾਂਝਾ ਕਰਨਾ (ਕੀ ਉਸਨੂੰ ਇਸ ਰਿਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਹੈ?). ਜੇ ਤੁਸੀਂ ਮਲਕੀਅਤ ਦੀ ਜਾਂਚ ਪਹਿਲਾਂ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਗੱਲ ਲੀਕ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਮੌਜੂਦ ਹੈ।
ਅਸਲ ਖਾਤਿਆਂ ਨਾਲ ਕੁਝ end-to-end ਟੈਸਟ ਚਲਾਓ, ਸਿਰਫ ਯੂਨਿਟ ਟੈਸਟ ਹੀ ਨਹੀਂ:
ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ (ਰੋਲ ਬਦਲ, ਮੈਂਬਰਸ਼ਿਪ ਹਟਾਉਣਾ, exports, deletes, ਸੈਟਿੰਗ ਅੱਪਡੇਟਸ) ਲਈ ਆਧਾਰਭੂਤ ਆਡੀਟ ਇਵੈਂਟ ਜੋੜੋ। ਪਹਿਲੇ ਦਿਨ ਤੇ 완ਪੂਰਨ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ, ਪਰ ਇਹ ਜਾਣਨਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ "ਕੌਣ, ਕਦੋਂ, ਕੀ ਕੀਤਾ"।
ਡਿਫਾਲਟਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ۔ ਨਵੇਂ ਆਰਗ ਅਤੇ ਨਵੇਂ ਮੈਂਬਰਾਂ ਨੂੰ ਉਹੀ ਘੱਟ ਤੋਂ ਘੱਟ ਪਹੁੰਚ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਸਫਲ ਹੋ ਸਕਣ। ਸਹਾਇਤਾ ਅਤੇ ਸੇਲਜ਼ ਲਈ ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ permission FAQ ਵੀ ਲਾਭਦਾਇਕ ਹੈ, ਉਦਾਹਰਨਾਂ ਨਾਲ ਜਿਵੇਂ "ਕੀ ਟੀਮ ਲੀਡ ਹੋਰ ਟੀਮਾਂ ਦੇਖ ਸਕਦਾ ਹੈ?" ਅਤੇ "ਕਿਸੇ ਨੂੰ ਹਟਾਉਣ ਤੋਂ ਬਾਅਦ ਪਹੁੰਚ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ?"۔
ਇੱਕ ਛੋਟੇ, ਅਸਲੀ ਸੈੱਟਅਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ ਗਾਹਕ ਕੰਪਨੀ (ਇੱਕ ਆਰਗ) ਦੋ ਟੀਮਾਂ ਨਾਲ, Sales ਅਤੇ Ops. ਸਭ ਇਕ ਵਾਰੀ ਸਾਇਨ-ਇਨ ਕਰਦੇ ਹਨ, ਫਿਰ ਉਹਨਾਂ ਦੀ ਆਰਗ ਚੁਣਦੇ ਹਨ। Sales ਨੂੰ customer records ਅਤੇ quotes ਦੀ ਲੋੜ ਹੈ। Ops ਨੂੰ billing ਅਤੇ ਅੰਦਰੂਨੀ ਸੈਟਿੰਗ ਦੀ ਲੋੜ ਹੈ।
ਟੀਮਾਂ ਨੂੰ ਗ੍ਰੁੱਪਿੰਗ ਅਤੇ ਵਰਕਫਲੋ ਵਜੋਂ ਰੱਖੋ, ਮੁੱਖ ਪਰਮੀਸ਼ਨ ਸਵਿੱਚ ਵਜੋਂ ਨਹੀਂ। ਉਹ defaults ਅਤੇ ਰੂਟਿੰਗ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਇੱਕੋ-ਮਾਤਰ ਗੇਟ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ।
ਚੋਣ ਕਰੋ ਇੱਕ ਛੋਟਾ ਰੋਲ ਸੈੱਟ ਅਤੇ ਜਦ ਤੱਕ ਫੀਚਰ ਆਉਂਦੇ ਜਾਂਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖੋ: Admin, Member, Viewer. ਰੋਲ ਇਹ ਪੁੱਛਦਾ ਹੈ "ਤੁਸੀਂ ਇਸ ਆਰਗ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦੇ ਹੋ?" ਸਕੋਪ ਪੁਛਦਾ ਹੈ "ਕਿੱਥੇ ਤੁਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹੋ?"
ਇਕ ਮਲਕੀਅਤ ਨਿਯਮ ਜੋੜੋ: ਹਰ ਸਰੋਤ ਦਾ ਇਕ ਆਰਗ ਅਤੇ ਇਕ ਮਾਲਕ (ਅਕਸਰ ਬਣਾਣ ਵਾਲਾ) ਹੁੰਦਾ ਹੈ। ਸੋਧ ਉਹਨਾਂ ਲਈ ਆਗਿਆ ਹੈ ਜੇ ਤੁਸੀਂ Admin ਹੋ, ਜਾਂ ਜੇ ਤੁਸੀਂ ਮਾਲਕ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਰੋਲ ਵਿੱਚ "edit own" ਸ਼ਾਮਿਲ ਹੈ۔ ਵੇਖਣਾ ਉਸ ਵੇਲੇ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੇ ਤੁਹਾਡੇ ਰੋਲ ਵਿੱਚ ਉਸ ਸਰੋਤ ਦੇ ਲਈ "view" ਹੈ।
ਉਦਾਹਾਰਣ: ਇੱਕ Sales Member ਇੱਕ quote ਬਣਾਂਦਾ ਹੈ। ਦੂਜਾ Sales Member ਉਸਨੂੰ ਵੇਖ ਸਕਦਾ ਹੈ, ਪਰ ਸੋਧ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਦ ਤੱਕ ਉਹ ਟੀਮ ਨਾਲ ਸਾਂਝਾ ਨਾ ਕੀਤਾ ਜਾਵੇ ਜਾਂ ਦੁਬਾਰਾ ਨਿਯੁਕਤ ਨਾ ਕੀਤਾ ਜਾਵੇ। ਇੱਕ Ops Viewer ਇਸਨੂੰ ਤਦ ਹੀ ਵੇਖ ਸਕੇਗਾ ਜੇ ਤੁਹਾਡੇ ਨਿਯਮ Ops ਨੂੰ Sales ਸਰੋਤ ਵੇਖਣ ਦੀ ਆਗਿਆ ਦੇਂਦੇ ਹਨ।
ਜਦੋਂ ਤੁਸੀਂ 200 ਗਾਹਕ ਆਰਗ ਆਨਬੋਰਡ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕੋ ਰੋਲ ਅਤੇ ਉਹੀ ਮਲਕੀਅਤ ਨਿਯਮ ਦੁਬਾਰਾ ਵਰਤਦੇ ਹੋ। ਤੁਸੀਂ ਮੈਂਬਰਸ਼ਿਪ ਬਦਲਦੇ ਹੋ, ਨਾ ਕਿ ਮਾਡਲ।
ਸਹਾਇਤਾ ਦੀਆਂ ਬੇਨਤੀਆਂ ਜਿਵੇਂ "ਕੀ ਤੁਸੀਂ X ਨੂੰ ਪਹੁੰਚ ਦੇ ਸਕਦੇ ਹੋ?" ਇੱਕ ਚੈਕਲਿਸਟ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਆਰਗ ਅਤੇ ਸਰੋਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਉਪਭੋਗੀ ਦਾ ਰੋਲ ਉਸ ਆਰਗ ਵਿੱਚ ਚੈੱਕ ਕਰੋ, ਮਲਕੀਅਤ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਰੋਲ ਬਦਲੋ ਜਾਂ ਸਰੋਤ ਸਾਂਝਾ ਕਰੋ۔ ਇੱਕ-ਵਾਰੀ ਛੂਟਾਂ ਤੋਂ ਬਚੋ ਅਤੇ ਇੱਕ ਆਡੀਟ ਨੋਟ ਛੱਡੋ۔
ਆਪਣੇ ਇਕ-ਪੰਨੇ ਮਾਡਲ ਨੂੰ ਇੱਕ ਠੇਕਾ ਸਮਝੋ۔ ਸਿਰਫ ਉਹ ਨਿਯਮ ਲਾਗੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਹਰ API ਕਾਲ ਅਤੇ ਹਰ UI ਸਕਰੀਨ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਨਹੀਂ ਤਾਂ ਅਧਿਕਾਰ "ਇਹ ਤੇ ਨਿਰਭਰ" ਵਿੱਚ ਡਿੱਗ ਜਾਂਦੇ ਹਨ।
ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕੁਝ ਰੋਲ, ਸਪਸ਼ਟ ਸਕੋਪ, ਅਤੇ ਸਧਾਰਣ ਮਲਕੀਅਤ। ਜਦੋ ਕੋਈ ਨਵਾਂ ਬੇਨਤੀ ਆਵੇ ("ਕੀ ਅਸੀਂ Editor-Manager ਰੋਲ ਜੋੜ ਸਕਦੇ ਹਾਂ?"), ਪਹਿਲਾਂ ਮਲਕੀਅਤ ਜਾਂ ਸਕੋਪ ਕਸੋਤ ਕਰੋ۔ ਨਵੇਂ ਰੋਲ ਘੱਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਹਰ ਨਵੇਂ ਸਰੋਤ ਲਈ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸੰਗਠਿਤ ਰੱਖੋ:
org_id ਸਟੋਰ ਕਰਦਾ ਹੋਵੇ (ਅਤੇ ਜੇ ਲਾਗੂ ਹੋਵੇ ਤਾਂ team_id)ਛੋਟੇ ਫਲੋਜ਼ ਨੂੰ ਪੋਲਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਫਲੋਜ਼ ਟੈਸਟ ਕਰੋ: ਨਿਮੰਤਰਣ, ਆਰਗ ਸਵਿੱਚ ਕਰਨਾ, ਐਡਮਿਨ ਪੇਜ, ਅਤੇ ਦੈਹਾਗ ਹੋਣ ਦੌਰਾਨ ਕਿਸੇ ਦੇ ਪਹੁੰਚ ਖਤਮ ਹੋਣ ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ۔
ਜੇ ਤੁਸੀਂ ਇੱਕ chat-based app builder ਨਾਲ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਸਾਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਮੀਸ਼ਨ ਮਾਡਲ ਲਿਖਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਪ੍ਰੋਡਕਟ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਨਾਲ ਰੱਖੋ। Koder.ai (koder.ai) 'ਤੇ Planning Mode ਨਾਲ snapshots ਅਤੇ rollback ਉਹ ਦ੍ਰਿਸ਼ਯ ਹਨ ਜੋ ਇਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਟ੍ਰਾਇਅਲ ਕਰਨ ਅਤੇ ਇਹ ਪੱਕਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਨਿਯਮ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਇੱਕੋ ਤਰ੍ਹਾਂ ਵਰਤਦੇ ਹਨ।