ਕਸਟਮ ਕੋਡ ਬਿਨਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਐਪ ਬਣਾਉਣ ਦੀ ਸਕੀਮ ਸਿੱਖੋ: ਕਦਮ ਨਕਸ਼ਾ ਬਣਾਓ, ਫਾਰਮ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਭੂਮਿਕਾਵਾਂ ਸੈਟ ਕਰੋ, ਰਾਊਟਿੰਗ ਆਟੋਮੇਟ ਕਰੋ, ਆਡਿਟ ਟ੍ਰੇਲ ਜੋੜੋ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਲਾਂਚ ਕਰੋ।
ਇੱਕ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਵੈਬ ਐਪ ਉਹ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਇਕ ਬੇਨਤੀ ਨੂੰ “ਕਿਸੇ ਨੂੰ ਕੁਝ ਚਾਹੀਦਾ ਹੈ” ਤੋਂ ਲੈਕੇ “ਫੈਸਲਾ ਹੋ ਗਿਆ—ਅਤੇ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਾਂ” ਤੱਕ ਲੈ ਜਾਂਦੀ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਿਸਟਮ ਕੁਝ ਮੁੱਖ ਕੰਮ ਸਥਿਰ ਢੰਗ ਨਾਲ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਟੀਮ ਦੇ ਹਿਸਾਬ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਵੱਖਰੀ ਹੋਵੇ।
ਜ਼ਿਆਦਾਤਰ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਪੈਟਰਨ ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ 'ਚ ਦੇਖੋਗੇ:
ਨੋ-ਕੋਡ ਟੂਲਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੇ ਫਿੱਟ ਹਨ ਕਿਉਂਕਿ ਇਹ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰਨ, ਹਰ ਹਫ਼ਤੇ ਅਪਡੇਟ ਕਰਨ, ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਲਕਾਂ ਕੋਲ ਸਵਾਮਿਤਾ ਰੱਖਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਫਾਰਮ, ਰਾਊਟਿੰਗ ਨਿਯਮ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਬਿਨਾਂ ਰਿਵਾਇਤੀ ਡਿਵ ਕਤਾਰ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਣਾਵ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਾਫੀ ਸ਼ਰਤਾਂ ਵਾਲੀ ਰਾਊਟਿੰਗ (ਕਈ ਸ਼ਾਖਾਵਾਂ), ਸਖਤ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਲੋੜਾਂ, ਕਸਟਮ SSO ਪਾਬੰਦੀਆਂ, ਜਾਂ ਉਹ ਕੁੰਜੀਆਂ ਬਣਦੀਆਂ ਹਨ ਜਿਹਨਾਂ ਲਈ ਮਿਡਲਵੇਅਰ ਅਤੇ ਮਜ਼ਬੂਤ ਐਰਰ ਹੈਂਡਲਿੰਗ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਇੰਜੀਨੀਅਰ ਲਿਆਓ। ਕਈ ਸੰਗਠਨਾਂ ਵਿੱਚ, ਨੋ-ਕੋਡ ਯੂਆਈ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਜਦਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਉਨ੍ਹਾਂ ਥਾਵਾਂ ਨੂੰ ਭਰ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਗੈਪ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ “ਕਸਟਮ” ਦੇ ਨੇੜੇ ਕੁਝ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਬਿਲਡ ਦੇ ਵਚਨਬੱਧ ਹੋਏ, ਇੱਕ ਵਾਇਬ-ਕੋਡਿੰਗ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਦਰਮਿਆਨੀ ਹੋ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵਰਕਫਲੋ ਦਾ ਵਰਣਨ ਕਰੋ, ਅਤੇ ਇਹ ਐਪ ਜੈਨਰੇਟ ਕਰਦਾ ਹੈ (ਆਮਤੌਰ 'ਤੇ ਫਰੰਟਐਂਡ 'ਤੇ React, ਬੈਕਐਂਡ 'ਤੇ Go + PostgreSQL) ਜਿਹੜੇ ਵਿੱਚ ਸੋర్స-ਕੋਡ ਐਕਸਪੋਰਟ, ਡੀਪਲੋਇਮੈਂਟ/ਹੁਸਟਿੰਗ, ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਜਿਹੜੀਆਂ ਵਿਕਲਪਿਕਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ—ਜਦੋਂ ਤੁਹਾਡਾ ਮਨਜ਼ੂਰੀ ਪ੍ਰਕਿਰਿਆ ساده ਤੋਂ ਕਠੋਰ ਹੋਵੇ।
ਬਿਲਡਰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ, ਪਹਿਲਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ ਚੁਣੋ। ਲੱਖ ਹੈ ਕਿ ਤੇਜ਼ੀ ਨਾਲ ਮੁੱਲ ਸਾਬਤ ਕਰਨਾ ਅਤੇ ਫਿਰ ਉਹੀ ਪੈਟਰਨ ਹੋਰ ਫਲੋਜ਼ ਲਈ ਦੁਹਰਾਉਣਾ।
ਇੱਕ ਚੰਗਾ ਪਹਿਲਾ ਉਮੀਦਵਾਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਗੁਣ ਰੱਖਦਾ ਹੈ:
ਉਦਾਹਰਣ: ਇੱਕ ਨਿਰਧਾਰਿਤ ਸੀਮਾ ਤੱਕ ਦੀਆਂ ਖਰੀਦ ਬੇਨਤੀਆਂ, ਛੁੱਟੀ ਦੀਆਂ ਮਨਜ਼ੂਰੀਆਂ, ਕਿਸੇ ਟੈਮਪਲੇਟ ਲਈ ਸਮੱਗਰੀ/ਕਾਨੂੰਨੀ ਸਮੀਖਿਆ, ਜਾਂ ਬੇਸਿਕ ਵੇਂਡਰ ਔਨਬੋਰਡਿੰਗ।
ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ ਤੁਹਾਡੇ ਫਾਰਮ-ਟੂ-ਮਨਜ਼ੂਰੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ “ਸਬਮਿਸ਼ਨ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ:
ਜੇ approvers ਹਮੇਸ਼ਾ ਇੱਕੋ ਹੀ ਗੁੰਝਲਦਾਰ ਵੇਰਵਾ ਮੰਗਦੇ ਹਨ, ਤਾਂ v1 ਵਿੱਚ ਉਸਨੂੰ ਜ਼ਰੂਰੀ ਬਣਾਓ।
ਹਰ ਵਿਅਕਤੀ (ਜਾਂ ਭੂਮਿਕਾ) ਲਿਖੋ ਅਤੇ ਜਿੱਥੇ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ ਉਹ ਦਰਜ ਕਰੋ: ਰਿਵੀਵਰ, approver, finance, legal, ਅਤੇ ਛੁੱਟੀਆਂ ਲਈ ਡੈਲੀਗੇਟ। ਉਹ “ਐਜ” ਫੈਸਲੇ ਵੀ ਨੋਟ ਕਰੋ ਜਿਵੇਂ “ਸੋਧ ਲਈ ਵਾਪਸ ਭੇਜੋ” ਜਾਂ “ਹੋਰ ਜਾਣਕਾਰੀ ਮੰਗੋ”, ਕਿਉਂਕਿ ਇਹ ਵੱਧਤਰ ਫਾਲੋਅੱਪ ਚਲਾਉਂਦੇ ਹਨ।
2–3 ਮਾਪਯੋਗ ਨਤੀਜੇ ਚੁਣੋ:
ਸ਼ੁਰੂ, ਅੰਤ, ਅਤੇ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕਸ ਨਾਲ, ਬਾਕੀ ਵਰਕਫਲੋ ਆਟੋਮੇਸ਼ਨ ਚੋਣ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਬਿਲਡਰ 'ਤੇ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪੰਨੇ 'ਤੇ ਮਨਜ਼ੂਰੀ ਮਾਰਗ ਨਕਸ਼ਾਬੱਧ ਕਰੋ। ਇਹ "ਲਗਭਗ ਚੱਲਦਾ ਹੈ" ਵਰਕਫਲੋਜ਼ ਨੂੰ ਰੋਕਦਾ—ਜਿੱਥੇ ਰਿਕਵੇਸਟ ਫਸ ਜਾਂਦੇ ਹਨ, ਗਲਤ ਵਿਅਕਤੀ ਕੋਲ ਰਾਹਤ ਹੁੰਦੇ ਹਨ, ਜਾਂ ਬਿਨਾਂ ਸਪਸ਼ਟ ਅਖੀਰ ਦੇ ਘੁੰਮਦੇ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਆਸਾਨ ਢਾਂਚਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਆਵਾਜ਼ ਵਿੱਚ ਪੜ੍ਹ ਸਕੋ:
Submit → Review → Approve/Reject → Close
ਹਰ ਕਦਮ ਲਈ ਦੱਸੋ ਕੌਣ ਕਰਦਾ ਹੈ (ਭੂਮਿਕਾ ਜਾਂ ਟੀਮ), ਉਹਨਾਂ ਨੂੰ ਕੀ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਕੀ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਕਦਮ ਨੂੰ ਇੱਕ ਵਰਕ ਵਿੱਚ ਇਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਦੱਸ ਸਕਦੇ, ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਕਾਰਵਾਈਆਂ ਲੁਕਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਜੋ ਵੱਖਰੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਸਮੀਖਿਆਆਂ:
ਪੈਰਲੇਲ ਫਲੋਜ਼ ਲਈ “ਮੁਕੰਮਲ” ਦਾ ਨਿਯਮ ਰੱਖੋ: ਸਭ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਕੋਈ ਇੱਕ ਕਾਫ਼ੀ ਹੈ, ਜਾਂ ਅਧਿਕੰਸ਼। ਅਜੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ—ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਅਕਸਰ ਰੀਬਿਲਡ ਮੰਗਦਾ ਹੈ।
ਇੱਕ ਨਾਕਾਰ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ:
ਕੰਪਲਾਇੰਸ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਜੋ ਸਹੀ ਹੈ ਉਹ ਚੁਣੋ। “ਸੋਧ ਅਤੇ ਦੁਬਾਰਾ ਜਮਾਂ” ਆਮ ਹੈ, ਪਰ ਤੁਸੀਂ ਮੂਲ ਫੈਸਲੇ ਨੂੰ ਵੀ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਅੱਗੇ-ਅੱਗੇ ਦੇ ਰਸਤੇ ਪੱਛੋਂ ਪਕੜੋ:
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕਾਗਜ਼ 'ਤੇ ਇਹਨਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਬਿਲਡ ਸੰਰਚਨਾ ਵਿਚਾਰਾਂ ਦੀ ਥਾਂ ਕੁਨਫਿਗਰੇਸ਼ਨ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਨੋ-ਕੋਡ ਮਨਜ਼ੂਰੀ ਐਪ ਸਭ ਤੋਂ ਵਧੀਆ ਤਬ ਹੁੰਦੀ ਹੈ ਜਦ ਡੇਟਾ ਮਾਡਲ ਸਧਾਰਨ, ਸਤਤ, ਅਤੇ ਬਾਅਦ 'ਚ ਰਿਪੋਰਟਿੰਗ ਲਈ ਆਸਾਨ ਹੋਵੇ। ਸਕ੍ਰੀਨ ਬਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਰਿਕਾਰਡ ਸਟੋਰ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਉਹ ਕਿਵੇਂ ਜੋੜੇ ਜਾਣਗੇ।
ਕਈ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋਜ਼ ਲਈ, ਕੁਝ ਟੇਬਲ/ਕਲੈਕਸ਼ਨਾਂ ਨਾਲ 90% ਜ਼ਰੂਰਤਾਂ ਕਵਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ:
Request ਨੂੰ ਇਕ ਸਿੰਗਲ ਸੋਸ ਆਫ਼ ਟ੍ਰੂਥ ਰੱਖੋ। ਬਾਕੀ ਸਭ ਕੁੱਝ ਇਸਦੇ ਨਾਲ ਜੋੜਿਆ ਹੋਵੇ।
ਰਞ典需होਰ... (ਪੂਰਾ)
ਇੱਕ ਐਹੋ ਜਿਹਾ ਵਰਕਫਲੋ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਉੱਚ ਦਰਦ, ਘੱਟ ਜਟਿਲਤਾ ਵਾਲਾ ਹੋਵੇ:
ਉਦਾਹਰਣਾਂ: ਥਰੈਸ਼ਹੋਲਡ ਤੋਂ ਘੱਟ ਖਰੀਦ ਦੀਆਂ ਬੇਨਤੀਆਂ, ਛੁੱਟੀ ਦੀ ਮਨਜ਼ੂਰੀ, ਜਾਂ ਮੂਲ ਪਹੁੰਚ ਬੇਨਤੀ ਫਲੋ। ਪਹਿਲਾਂ ਵੈਲੂ ਸਬੂਤ ਕਰੋ, ਫਿਰ ਹੋਰ ਫਲੋਜ਼ 'ਤੇ ਇਹੀ ਪੈਟਰਨ ਦੁਹਰਾਓ।
ਉਹ ਘੱਟੋ-ਘੱਟ ਡੇਟਾ ਲਓ ਜੋ ਰਾਊਟਿੰਗ ਅਤੇ ਫੈਸਲਾ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਹਨ। ਆਮ ਲਾਜ਼ਮੀ ਫੀਲਡ:
ਜੇ approvers ਵਾਰ-ਵਾਰ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਜਾਣਕਾਰੀ (ਜਿਵੇਂ vendor ਨਾਮ ਜਾਂ quote) ਲਈ ਪੁੱਛਦੇ ਹਨ, ਤਾਂ v1 ਵਿੱਚ ਉਸਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਓ।
ਅਧਿਕਤਰ ਐਪਸ ਨੂੰ ਬਸ ਕੁਝ ਮੁੱਖ ਸਕ੍ਰੀਨ ਚਾਹੀਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ:
ਨੈਵੀਗੇਸ਼ਨ ਸਧਾਰਨ ਰੱਖੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਆਸਾਨੀ ਨਾਲ “New request”, “My requests”, ਅਤੇ “Needs my approval” ਲੱਭ ਸਕਣ।
ਫਿਲਟਰਿੰਗ, ਰਿਮਾਇੰਡਰ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਛੋਟੀ, ਮਿਆਰੀ ਸਥਿਤੀ ਸੈੱਟ ਵਰਤੋ:
ਜੇ ਵਧੇਰੇ ਵੇਰਵਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਮੌਜੂਦਾ ਕਦਮ (ਜਿਵੇਂ “Manager review”) ਵੱਖਰੇ ਫੀਲਡ ਵਜੋਂ ਦਿਖਾਓ, ਬੇਕਾਰ ਦੇ ਕਈ ਸਟੈਟਸ ਨਾ ਬਣਾਓ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਤਰੀਕਾ ਮੱਥੇ/ਗਤੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ:
ਪੈਰਲੇਲ ਸਮੀਖਿਆ ਲਈ ਧਿਆਨ ਨਾਲ ਨਿਯਮ ਤੈਅ ਕਰੋ: ਸਭ ਦੀ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ, ਕੋਈ ਇਕੀ genoeg, ਜਾਂ ਅਧਿਕੰਸ਼—ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਮੁਸ਼ਕਿਲ ਕਰ ਸਕਦਾ ਹੈ।
ਆਪਣੇ ਪ੍ਰਕਿਰਿਆ ਲਈ “reject” ਦਾ ਮਤਲਬ ਤੈਅ ਕਰੋ:
ਚਾਹੇ edit/resubmit ਹੋਵੇ, ਮੁਢਲੇ ਫੈਸਲੇ ਅਤੇ ਨਾਕਾਰਣ ਦੀ ਵਜ੍ਹਾ ਦਾ ਆਡਿਟ ਰਿਕਾਰਡ ਰੱਖੋ।
ਪ੍ਰਤਿਯੋਗ ਦੇ ਮੰਚ ਤੇ ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਅਧਿਕਾਰ ਪਰਕਿਰਿਆ ਅਨੁਸਾਰ ਤੈਅ ਕਰੋ:
ਪ੍ਰਯੋਗਕ ਰੱਖਰੂਪ: ਇੱਕ ਵਾਰੀ ਸਬਮਿਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਮੁੱਖ ਫੀਲਡ ਲਾਕ ਹੋ ਜਾਣ, ਅਤੇ ਸੋਧਾਂ ਨੂੰ “send back” ਕਾਰਵਾਈ ਰਾਹੀਂ ਹੀ ਆਗਿਆ ਹੋਵੇ।
ਲੋਗ-ਅਧਾਰਿਤ ਨਿਯਮ ਵਰਤੋਂ ਨਾ ਕਿ ਨਾਂਮਾਂ ਨੂੰ ਹਾਰਡਕੋਡ ਕਰੋ:
ਇਸ ਤਰ੍ਹਾਂ ਲੋਕਾਂ ਦੇ ਬਦਲਣ 'ਤੇ ਰਾਊਟਿੰਗ ਸਹੀ ਰਹੇਗੀ।
ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਰੋਕਥਾਮ ਨਿਯਮ ਜੋੜੋ ਤਾਂ ਕਿ ਮਨਜ਼ੂਰੀਆਂ ਰੁਕੀ ਨਾ ਰਹਿਣ:
ਏਸਕੇਲੇਸ਼ਨ ਵਿਵਹਾਰ ਦਿੱਸਣਯੋਗ ਅਤੇ ਨਿਰਧਾਰਤ ਹੋਵੇ ਤਾਂ ਲੋਕ ਸਿਸਟਮ 'ਤੇ ਭਰੋਸਾ ਕਰਨਗੇ।
ਆਡਿਟ ਟਰੇਲ ਜੋ “ਕਿਸ ਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ” ਨੂੰ ਜਵਾਬ ਦੇ ਸਕੇ:
ਰਿਟੇਨਸ਼ਨ ਨਿਯਮ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ (ਜਿਵੇਂ 12–24 ਮਹੀਨੇ) ਅਤੇ least-privilege ਅਕਸਰ ਵਰਤੋ ਤਾਂ ਕਿ ਲੋਕਾਂ ਨੂੰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੋੜ ਹੈ ਉਹੀ ਦਿਖੇ।
