ਕੇਂਦਰੀ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਲਈ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ

ਕੇਂਦਰੀ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ

ਕੇਂਦਰੀ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸੰਗਠਨ ਕੋਲ ਇੱਕ ਭਰੋਸੇਯੋਗ ਥਾਂ ਹੋਵੇ ਜਿੱਥੇ ਨੀਤੀਆਂ ਬਣਾਈਆਂ, ਸੰਭਾਲੀਆਂ, ਪ੍ਰਕਾਸ਼ਿਤ ਅਤੇ ਸਮਝ ਦਾ ਸਬੂਤ ਦਿੰਦੇ ਹੋਏ ਰੱਖੀਆਂ ਜਾਣ। ਇਹ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ "ਸਟੋਰੇਜ" ਬਾਰੇ ਨਹੀਂ—ਬਲਕਿ ਪੂਰੇ ਨੀਤੀ ਲਾਈਫਸਾਈਕਲ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਬਾਰੇ ਹੈ: ਹਰ ਨੀਤੀ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਕਿਹੜਾ ਵਰਜ਼ਨ ਕਰੰਟ ਹੈ, ਕਿਸ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ, ਅਤੇ ਕੌਣ ਨੇ ਸਵੀਕਾਰ ਕੀਤਾ।

ਉਹ ਮੁਸ਼ਕਲਾਂ ਜੋ ਤੁਸੀਂ ਖਤਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ

ਅਧਿਕਤਰ ਸੰਗਠਨਾਂ ਨੂੰ “ਨੀਤੀ ਪ੍ਰਬੰਧਨ” ਕਹਿਣ ਤੋਂ ਕਾਫੀ ਪਹਿਲਾਂ ਹੀ ਦਰਦ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਆਮ ਮੁੱਦੇ ਇਹ ਹਨ:

• ਫੈਲਿਆ ਹੋਇਆ ਸਚਾਈ ਦਾ ਸਰੋਤ: ਨੀਤੀਆਂ ਸਾਂਝੇ ਡ੍ਰਾਇਵ, ਈਮੇਲ ਥਰੇਡ, PDF, ਵਿਕੀ ਅਤੇ HR ਟੂਲਜ਼ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ—ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਤਾਜ਼ਾ ਕੌਣ ਸੀ।
• ਪੁਰਾਣੇ ਵਰਜ਼ਨ ਫਾਇਲਾਂ ਵਿੱਚ ਘੁਮਦੇ ਰਹਿਣਾ: ਕਰਮਚਾਰੀ ਪੁਰਾਣੇ ਲਿੰਕਾਂ ਨੂੰ ਬੁੱਕਮਾਰਕ ਕਰ ਲੈਂਦੇ ਹਨ ਜਾਂ PDF ਡਾਊਨਲੋਡ ਕਰ ਲੈਂਦੇ ਹਨ; ਆਡੀਟਰ ਟੀਮਾਂ ਵਿਚ ਵਿਚਕਾਰ ਅਸਮਾਨਤਾ ਲੱਭ ਲੈਂਦੇ ਹਨ।
• ਅਸਪਸ਼ਟ ਮਾਲਕੀ: "ਇਸ ਨੂੰ ਕੌਣ ਸੰਭਾਲਦਾ ਹੈ?" ਬਾਰ-ਬਾਰ ਉਠਦਾ ਹੈ ਅਤੇ ਨੀਤੀਆਂ ਖਾਮੋਸ਼ੀ ਨਾਲ ਮੁੜ ਵੇਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• ਧੀਮੀ, ਬੇਫਰਮਾ ਸਮੀਖਿਆ ਚੱਕਰ: ਮਨਜ਼ੂਰੀਆਂ ਚੈਟ ਜਾਂ ਈਮੇਲ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਕੋਈ ਯਕੀਨੀ ਚੈੱਕਲਿਸਟ ਜਾਂ ਰਿਕਾਰਡ ਨਹੀਂ ਰਹਿੰਦਾ।
• ਖਰਾਬ ਅਪਨਾਉਣ: ਕਰਮਚਾਰੀ ਸਬੰਧਿਤ ਨੀਤੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭ ਪਾਂਦੇ, ਜਾਂ ਸਮਝਦੇ ਹੀ ਨਹੀਂ ਕਿ ਕੀ ਬਦਲਿਆ।

ਇੱਕ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਵੈੱਬ ਐਪ ਇਨ੍ਹਾਂ ਫੇਲਿਆਂ ਨੂੰ ਘਟਾ ਦੇਵੇਗਾ—ਮੌਜੂਦਾ ਵਰਜ਼ਨ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਕੇ, ਜ਼ਿੰਮੇਦਾਰੀ ਦੇ ਕੇ, ਅਤੇ ਸਮੀਖਿਆ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਨੂੰ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰਕੇ।

ਸਿਸਟਮ ਨੂੰ ਕਿਸ ਨੂੰ ਸੇਵਾ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ

ਸ਼ੁਰੂ ਤੋਂ ਘੱਟੋ-ਘੱਟ ਚਾਰ ਯੂਜ਼ਰ ਕਿਸਮਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ:

• ਨੀਤੀ ਮਾਲਕ (ਲਿਖਦੇ ਅਤੇ ਅਪਡੇਟ ਕਰਦੇ ਹਨ)
• ਸਮੀਖਿਆਕਾਰ/ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੇ (ਕਾਨੂੰਨੀ, ਸੁਰੱਖਿਆ, HR, ਲੀਡਰਸ਼ਿਪ)
• ਕਰਮਚਾਰੀ (ਪੜ੍ਹਨ, ਖੋਜ, ਸਵੀਕਾਰ ਕਰਨਾ)
• ਆਡੀਟਰ/ਕੰਪਲਾਇੰਸ (ਇਤਿਹਾਸ ਅਤੇ ਸਬੂਤ ਦੀ ਜਾਂਚ)

ਹਰ ਗਰੁੱਪ ਦੀ "ਕੰਮ ਕਰਨ" ਦੀ ਪੱਧਰ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ: ਮਾਲਕ ਆਸਾਨ ਸੋਧਾਂ ਚਾਹੁੰਦੇ ਹਨ, ਕਰਮਚਾਰੀ ਤੇਜ਼ ਨਤੀਜੇ, ਤੇ ਆਡੀਟਰ ਸਬੂਤ।

ਸ਼ੁਰੂਆਤੀ ਸਖਤ ਪਰिधੀ ਚੁਣੋ ਜੋ ਰੀਲ ਸ਼ਿਪ ਕਰੇ

ਇੱਕ ਸੀਮਿਤ ਡੋਮੇਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅਸਲੀ ਵਰਕਫਲੋ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਦੇ ਸਕੋਗੇ—ਸਿਰਫ਼ ਰਿਪੋਜ਼ਟਰੀ ਨਹੀਂ। ਆਮ ਤੌਰ 'ਤੇ IT/ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚੰਗਾ ਹੈ (ਵੱਧਾ ਬਦਲਾਅ, ਸਪਸ਼ਟ ਕੰਟਰੋਲ)।

ਤੁਹਾਡਾ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਦੋ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਤੁਰੰਤ ਦੇਵੇ:

• ਮੌਜੂਦਾ ਨੀਤੀ ਕੀ ਹੈ?
• ਸਾਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਸਮੀਖਿਆ ਅਤੇ ਸਾਂਝਾ ਕੀਤੀ ਗਈ ਸੀ?

ਮੁੱਖ ਲੋੜਾਂ: ਲਾਈਫਸਾਈਕਲ, ਮਾਲਕੀ, ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ

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

ਇੱਕ ਐਸੀ ਨੀਤੀ ਲਾਈਫਸਾਈਕਲ ਜੋ ਤੁਸੀਂ "ਭੁੱਲ" ਨਾ ਸਕੋ

ਨੀਤੀਆਂ ਨੂੰ ਜੀਵਤ ਸੰਪਤੀ ਵਜੋਂ ਮਾਨੋ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਸੂਚਿਤ ਸਥਿਤੀਆਂ ਹਨ: Draft → In Review → Approved → Published → Retired। ਹਰ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਜਾਣ-ਬੂਝ ਕੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਅਕਸਰ ਪਰਮੀਸ਼ਨ ਵਾਲੀ), ਤਾਂ ਜੋ ਇਕ ਡਰਾਫਟ ਚੁਪਕੇ ਤੋਂ "ਆਧਿਕਾਰਿਕ" ਨਾ ਬਣੇ ਅਤੇ ਇਕ ਰਿਟਾਇਰ ਕੀਤੀ ਨੀਤੀ ਗਲਤੀ ਨਾਲ ਮੁੜ ਵਰਤੀ ਨਾ ਜਾਵੇ।

ਘੱਟੋ-ਘੱਟ ਸ਼ਾਮਲ ਕਰੋ:

• ਇੱਕ ਦਿੱਖ ਵਾਲੀ ਸਟੇਟਸ ਬੈਜ ਅਤੇ ਆਖ਼ਰੀ ਅੱਪਡੇਟ ਤਾਰੀਖ
• ਨਿਯਤ ਸਮੀਖਿਆ ਮਿਤੀਆਂ (ਉਦਾਹਰਨ ਲਈ 12 ਮਹੀਨੇ)
• ਸਪਸ਼ਟ "ਅਗਲਾ ਕਦਮ" ਪ੍ਰਾਰੰਭ (ਸਮੀਖਿਆ ਲਈ ਜਮ੍ਹਾਂ ਕਰੋ, ਮਨਜ਼ੂਰੀ ਮੰਗੋ, ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ)

ਮਾਲਕੀ ਸਪਸ਼ਟ (ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰਨਯੋਗ)

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

ਸ਼ੁਰੂ ਵਿੱਚ ਨੀਤੀ ਕਿਸਮਾਂ ਅਤੇ ਵਰਗੀਕਰਨ ਤੈਅ ਕਰੋ—HR, ਸੁਰੱਖਿਆ, ਫਾਇਨੈਂਸ, ਵੇਂਡਰ ਪ੍ਰਬੰਧਨ ਆਦਿ। ਵਰਗੀਕਰਨ ਅਧਿਕਾਰ, ਸਮੀਖਿਆ ਰੂਟਿੰਗ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਛੱਡ ਦੇਵੋਗੇ, ਤਾਂ ਤੁਹਾਡਾ ਰਿਪੋਜ਼ਟਰੀ ਐਸੀ ਥਾਂ ਬਣ ਜਾਵੇਗੀ ਜਿਸ ਵਿੱਚ ਕਿਸੇ ਨੂੰ ਰਸਤਾ ਨਹੀਂ ਮਿਲੇगा।

ਜ਼ਿੰਮੇਵਾਰੀ: ਅਟੈਸਟੇਸ਼ਨ, ਆਡਿਟ ਅਤੇ ਰਿਪੋਰਟਿੰਗ

ਕੇਂਦਰੀਕਰਨ ਦਾ ਮੁੱਲ ਉਹੀ ਹੈ ਜੇ ਤੁਸੀਂ ਦਿਖਾ ਸਕੋ ਕਿ ਕਿਸ ਨੂੰ ਕਦੋਂ ਕੀ ਪਤਾ ਸੀ।

ਅਟੈਸਟੇਸ਼ਨ ਇਹ ਜਵਾਬ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ:

• ਕੌਣ ਮਨਜ਼ੂਰ ਕਰੇਗਾ (ਸਾਰੀਆਂ ਸਟਾਫ, ਨਿਰਧਾਰਤ ਵਿਭਾਗ, ਜਾਂ ਕਸਟਮ ਗਰੁੱਪ)
• ਕਿੰਨੀ ਵਾਰ (ਪ੍ਰਕਾਸ਼ਨ ਸਮੇਂ, ਸਾਲਾਨਾ, ਵੱਡੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ)
• ਯਾਦਦਿਹਾਨੀਆਂ ਅਤੇ ਐਸਕਲੇਸ਼ਨ (ਆਟੋ ਨੱਜ, ਬਕਾਇਆ ਨੋਟੀਫਿਕੇਸ਼ਨ)

ਆਡਿਟ ਲਈ, ਦਰਜ ਕਰੋ ਕਿਸ ਨੇ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ, ਅਤੇ ਕਿਉਂ। "ਕਿਉਂ" ਮਹੱਤਵਪੂਰਣ ਹੈ—ਛੋਟਾ ਕਾਰਨ ਲਿਬ ਕਰੋ ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਟਿਕਟ ਜਾਂ ਇੰਸੀਡੈਂਟ ਰੈਫਰੈਂਸ ਦਾ ਹਵਾਲਾ ਦਿਓ।

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

ਯੂਜ਼ਰ ਰੋਲ ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ (RBAC)

RBAC ਤੁਹਾਡੇ ਐਪ ਲਈ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ edit ਜਾਂ approve) ਅਤੇ ਕੌਣ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ (ਕੰਹੜੀਆਂ ਨੀਤੀਆਂ ਕਿਸ ਨੂੰ ਦਿਖਾਈਆਂ ਜਾਣ)। ਇਨ੍ਹਾਂ ਨੂੰ ਸ਼ੁਰੂ 'ਚ ਠੀਕ ਮਿਲਾ ਲੈਣ ਨਾਲ ਗਲਤੀ ਵਾਲੀਆਂ ਸੋਧਾਂ, ਮਨਜ਼ੂਰੀ ਛਲਾਂ ਅਤੇ ਨੀਤੀਆਂ ਦੇ "ਸ਼ੈੱਡੋ ਕਾਪੀ" ਬਚਾਏ ਜਾ ਸਕਦੇ ਹਨ।

ਸਮਰੱਥ ਰੋਲ ਜੋ ਸਪੋਰਟ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ

ਪ੍ਰਯੋਗਕਲਪਨਕ ਪਹਿਲੀ ਸੈੱਟ:

• ਐਡਮਿਨ: ਆਰਗ ਸੈਟਿੰਗ, ਯੂਜ਼ਰ, ਰੋਲ ਅਸਾਈਨਮੈਂਟ; ਐਕਸੈਸ ਦੇ ਸਕਦਾ/ਕੱਦੀ ਅਤੇ ਗਲਤੀਆਂ ਤੋਂ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ
• ਨੀਤੀ ਮਾਲਕ: ਨਿਰਧਾਰਿਤ ਨੀਤੀਆਂ ਲਈ ਡਰਾਫਟ ਬਣਾਉਂਦਾ/ਸੰਪਾਦਨ ਕਰਦਾ, ਸਮੀਖਿਆ ਫੀਡਬੈਕ ਦਾ ਜਵਾਬ ਦਿੰਦਾ, ਮਨਜ਼ੂਰੀ ਸ਼ੁਰੂ ਕਰਦਾ
• ਸਮੀਖਿਆਕਾਰ/ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ: ਟਿੱਪਣੀ ਕਰ ਸਕਦਾ, ਬਦਲਾਅ ਮੰਗ ਸਕਦਾ, ਵਰਜ਼ਨ ਮਨਜ਼ੂਰ/ਰੱਦ ਕਰ ਸਕਦਾ
• ਕਰਮਚਾਰੀ/ਪਾਠਕ: ਪ੍ਰਕਾਸ਼ਿਤ ਨੀਤੀਆਂ ਦਾ ਰੀਡ-ਓਨਲੀ ਅਕਸੈਸ
• ਆਡੀਟਰ (ਰੇਡ-ਓਨਲੀ): ਪ੍ਰਕਾਸ਼ਿਤ ਨੀਤੀਆਂ ਅਤੇ ਕੰਪਲਾਇੰਸ ਸਬੂਤ ਦੇਖ ਸਕਦਾ

ਕਾਰਵਾਈਆਂ: ਉਹ ਪਰਮਿਸ਼ਨਾਂ ਜੋ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ

ਹਕੀਕਤ-ਕੇਂਦਰਤ ਵਰਕਫਲੋ ਕਦਮਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਪਰिभਾਸ਼ਿਤ ਕਰੋ: create, edit draft, submit for review, approve, publish, unpublish, ਅਤੇ manage targets। ਰੋਲਾਂ ਨਾਲ ਪਰਬੰਧ ਕਰੋ ਪਰ ਕੁਝ Ausnahme ਦੀ ਜਗ੍ਹਾ ਰੱਖੋ (ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਸਿਰਫ HR ਨੀਤੀਆਂ ਦੀ ਮਾਲਕੀ ਮਿਲੇ)।

ਵਿਜ਼ਿਬਿਲਟੀ ਟਾਰਗੇਟਿੰਗ (ਵਿਭਾਗ/ਸਥਾਨ)

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

ਪ੍ਰਮਾਣਿਕਤਾ ਚੋਣ: SSO ਵਿਰੁੱਧ ਈਮੇਲ/ਪਾਸਵਰਡ

ਕਈ ਸੰਸਥਾਵਾਂ ਲਈ SSO (SAML/OIDC) ਸਪੋਰਟ ਦਿਨ ਨਾਲ ਸਪੋਰਟ ਸਮੱਸਿਆਵਾਂ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ। ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ, ਈਮੇਲ/ਪਾਸਵਰਡ ਕਬੂਲਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਬੇਸਿਕਸ ਜਿਵੇਂ ਪਾਸਵਰਡ ਰੀਸੈਟ ਅਤੇ MFA ਵਿਕਲਪ ਸ਼ਾਮਲ ਕਰੋ—ਸਿਰਫ਼ ਅਪਗਰੇਡ ਪਾਥ ਸਪਸ਼ਟ ਹੋਵੇ।

ਐਡਜ ਕੇਸ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਿਤ ਕਰੋ

ਉਹ ਨਿਯਮ ਲਿਖੋ ਜੋ ਟਕਰਾਅ ਰੁਕਣ ਅਤੇ "ਮਨਜ਼ੂਰੀ ਰੰਗਰੱਬੇਜ਼" ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ, ਜਿਵੇਂ:

• ਮਾਲਕ ਆਪਣੀ ਸੋਧ ਨੂੰ ਖੁਦ ਮਨਜ਼ੂਰ ਨਾ ਕਰ ਸਕੇ
• ਐਡਮਿਨਾਂ ਨੂੰ ਬਿਨਾਂ ਲਿਖਤ ਕਾਰਨ ਦਿਖਾਏ ਮਨਜ਼ੂਰੀ ਗਾਲੀਆਂ ਨਹੀਂ ਮਿਲਣੇ (ਜੇ ਕਰਦੇ ਹਨ ਤਾਂ ਕਾਰਨ ਦਰਜ ਹੋਵੇ)
• ਰੋਲ ਬਦਲਾਅ ਇਤਿਹਾਸ ਨੂੰ ਮੁੜ-ਲਿਖ ਨਾ ਸਕੇ (ਪਿਛਲੇ ਕਾਰਵਾਈਆਂ ਉਹੀ ਯੂਜ਼ਰ ਅਤੇ ਰੋਲ ਦੇ ਨਾਂ 'ਤੇ ਰਹਿਣ)

ਡੇਟਾ ਮਾਡਲ: ਨੀਤੀਆਂ, ਵਰਜ਼ਨ, ਅਤੇ ਮੈਟਾਡੇਟਾ

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

“Policy” ਰਿਕਾਰਡ: ਸਥਿਰ ਪਹਚਾਨ

ਇੱਕ Policy ਨੂੰ ਉਹ ਹੋਲਡਰ ਮੰਨੋ ਜੋ ਸਮੱਗਰੀ ਦੇ ਵਿਕਾਸ ਦੁਆਰਾਨ ਇਕੋ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਲਾਭਦਾਇਕ ਫੀਲਡਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਸਿਰਲੇਖ ਅਤੇ ਛੋਟਾ ਸੰਖੇਪ (ਇਹ ਕੀ ਹੈ, ਕਿਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ)
• ਮਾਲਕ (ਵਿਅਕਤੀ ਜਾਂ ਟੀਮ)
• ਸਤਿਤੀ (Draft, In Review, Approved, Published, Retired)
• ਸ਼੍ਰੇਣੀ (HR, Security, Finance ਆਦਿ)
• ਪ੍ਰਭਾਵी ਮਿਤੀ (ਜਦੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਵਰਜ਼ਨ ਲਾਗੂ ਹੁੰਦਾ)
• ਸਮੀਖਿਆ ਅੰਤਰਾਲ (ਉਦਾਹਰਣ: ਹਰ 12 ਮਹੀਨੇ) ਅਤੇ ਅਗਲੀ ਸਮੀਖਿਆ ਮਿਤੀ (ਮੁਲDerived ਹੋ ਸਕਦੀ ਹੈ)

ਇਹ ਫੀਲਡ ਹਲਕੇ ਅਤੇ ਮਿਆਰੀਕ੍ਰਿਤ ਰੱਖੋ—ਯੂਜ਼ਰ ਇਕ ਨਜ਼ਰ ਵਿੱਚ ਨੀਤੀ ਨੂੰ ਸਮਝਣ ਲਈ ਉਨ੍ਹਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ।

ਨੀਤੀ ਸਮਗਰੀ ਸਟੋਰ ਕਰਨਾ: ਪ੍ਰাথমিক ਫਾਰਮੈਟ ਚੁਣੋ

ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਵਿਕਲਪ ਹਨ:

• ਰਿਚ ਟੈਕਸਟ ਐਡੀਟਰ: ਬ੍ਰਾਉਜ਼ਰ-ਅਧਾਰਿਤ ਸੋਧ ਲਈ ਭਲਾ
• Markdown: ਤੇਜ਼ ਸੋਧ ਅਤੇ ਸਾਫ਼ ਡਿਫ਼ ਲਈ ਵਧੀਆ
• ਫਾਈਲ ਅੱਪਲੋਡ (PDF/DOCX): ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ, ਪਰ ਖੋਜ ਅਤੇ ਤੁਲਨਾ ਵਿੱਚ ਮੁਸ਼ਕਲ

ਅਧਿਕਤਰ ਟੀਮ ਪਹਿਲਾਂ ਫਾਈਲ ਅੱਪਲੋਡ ਸਹਾਰਨ ਦੀ ਸਹਾਇਤਾ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਮੈਚਰ ਹੋਣ 'ਤੇ ਰਿਚ ਟੈਕਸਟ/Markdown ਤੇ ਚਲਦੀਆਂ ਹਨ।

ਵਰਜ਼ਨਿੰਗ: ਅਟੁੱਟ ਵਰਜ਼ਨ + “ਕਰੰਟ” ਪਾਇੰਟਰ

ਅਟੁੱਟ PolicyVersion ਰਿਕਾਰਡ ਵਰਤੋ (ਵਰਜ਼ਨ ਨੰਬਰ, ਬਣਾਉਣ ਸਮਾਂ, ਲੇਖਕ, ਸਮੱਗਰੀ ਸਨੈਪਸ਼ਾਟ)। ਮਾਤਾ Policy current_version_idActive ਵਰਜ਼ਨ ਵੱਲ ਇੰਗਿਤ ਕਰੇ। ਇਹ ਇਤਿਹਾਸ ਨੂੰ ਓਵਰਰਾਈਟ ਹੋਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰੀ/ਆਡਿਟ ਨੂੰ ਸਾਫ਼ ਬਣਾਉਂਦਾ ਹੈ।

ਅਟੈਚਮੈਂਟ, ਹਵਾਲੇ ਅਤੇ ਖੋਜ ਲਈ ਮੈਟਾਡੇਟਾ

Attachments (ਫਾਈਲਾਂ) ਅਤੇ References (URLs ਤੱਕ ਸੰਦਰਭ) ਨੂੰ ਵੱਖ-ਵੱਖ ਲਿੰਕ ਕੀਤੇ ਰਿਕਾਰਡ ਵਜੋਂ ਮਾਡਲ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਅਤੇ ਅਪਡੇਟ ਕੀਤੇ ਜਾ ਸਕਣ।

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

ਵਰਕਫਲੋ ਡਿਜ਼ਾਈਨ: ਡਰਾਫਟ, ਸਮੀਖਿਆ, ਅਤੇ ਮਨਜ਼ੂਰੀ

ਜਦੋਂ "ਨਵਾਂ ਵਿਚਾਰ" ਤੋਂ "ਆਧਿਕਾਰਿਕ ਨੀਤੀ" ਤੱਕ ਦਾ ਰਾਹ ਪੇਸ਼ਗੋਈਯੋਗ ਹੋਵੇ ਤਾਂ ਰਿਪੋਜ਼ਟਰੀ ਲਾਭਦਾਇਕ ਬਣਦੀ ਹੈ। ਤੁਹਾਡਾ ਵਰਕਫਲੋ ਕਮਪਲਾਇੰਸ ਲਈ ਕਾਫੀ ਸਖਤ ਪਰ ਬਿਜੀ ਸਮੀਖਿਆਕਾਰਾਂ ਲਈ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਸਟੇਟ ਮਸ਼ੀਨ (ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਫਾਲੋ ਕਰਨ)

ਛੋਟੇ ਸੈੱਟ ਸਟੇਟਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਜਗ੍ਹਾ ਦਿਖਾਈ ਦੇਣ: Draft → In Review → Approved → Published → Retired।

ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਪਰਮੀਸ਼ਨ-ਅਧਾਰਤ ਬਣਾਓ:

• Draft → In Review: ਲੇਖਕ ਸਮੀਖਿਆ ਲਈ ਬੇਨਤੀ ਕਰਦਾ ਅਤੇ ਲਾਜ਼ਮੀ ਅਨੁਮੋਦਕ ਚੁਣਦਾ
• In Review → Approved: ਸਾਰੇ ਲਾਜ਼ਮੀ ਮਨਜ਼ੂਰੀਆਂ ਇਕੱਠੀਆਂ ਹੋਣ
• Approved → Published: ਪ੍ਰਕਾਸ਼ਕ (ਜਾਂ ਨੀਤੀ ਮਾਲਕ) ਆਡਿਟ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਦਾ
• Published → Retired: ਨੀਤੀ ਨੂੰ ਬਦਲ ਕੇ ਜਾਂ ਡਿਪ੍ਰੀਕੇਟ ਕਰਕੇ ਹਟਾਇਆ ਜਾਂਦਾ

ਛੁਪੇ ਹੋਏ ਸਟੇਟਸ ਤੋਂ ਬਚੋ। ਜੇ ਤੁਸੀਂ ਨੁੱਕੜੀ ਦਰਕਾਰ ਹੋ ਤਾਂ Needs Legal ਜਾਂ Blocked by Evidence ਵਰਗੇ ਟੈਗ ਰੱਖੋ ਨਾ ਕਿ ਵਧੇਰੇ ਸਟੇਟਸ।

ਮਨਜ਼ੂਰੀ: ਕਦਮ, ਲਾਜ਼ਮੀ ਅਨੁਮੋਦਕ, ਅਤੇ ਲਚਕੀਲਾ ਰੂਟਿੰਗ

ਮਨਜ਼ੂਰੀਆਂ ਨੂੰ ਇੱਕ ਕਦਮ ਵਜੋਂ ਮਾਡਲ ਕਰੋ ਜਿਸ ਵਿੱਚ ਲਾਜ਼ਮੀ ਅਨੁਮੋਦਕਾਂ ਦੀ ਸੂਚੀ ਹੋਵੇ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਸਮਰਥਨ ਕਰ ਸਕਦੇ:

• ਕ੍ਰਮਵਾਰ ਮਨਜ਼ੂਰੀਆਂ (ਉਦਾਹਰਣ: Owner → Legal → Security)
• ਸਮਾਂਤਰ ਮਨਜ਼ੂਰੀਆਂ (ਉਦਾਹਰਣ: Legal ਅਤੇ Security ਇਕੱਠੇ)

ਹਰ ਕਦਮ ਪੂਰਾ ਕਰਨ ਦੇ ਨਿਯਮ ਵਿਵਰਿਤ ਕਰੇ—ਜਿਵੇਂ "3 ਵਿੱਚੋਂ 2" ਜਾਂ "ਸਾਰੇ"। ਇਹ ਨੀਤੀ ਕਿਸਮ-ਅਨੁਸਾਰ ਕਾਂਫਿਗਰ ਕਰਨਯੋਗ ਰੱਖੋ।

ਟਿੱਪਣੀਆਂ, ਬਦਲਾਅ ਦੀਆਂ ਬੇਨਤੀਆਂ, ਅਤੇ ਟਾਸਕ ਅਸਾਈਨਮੈਂਟ

ਸਮੀਖਿਆਕਾਰਾਂ ਨੂੰ structured ਤਰੀਕੇ ਨਾਲ "ਹਜੇ ਨਹੀਂ" ਕਹਿਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੁਹੱਈਆ ਕਰੋ:

• ਇਨਲਾਈਨ ਟਿੱਪਣੀਆਂ (ਇਕ ਸੈਕਸ਼ਨ ਨਾਲ ਜੋੜੀਆਂ) ਅਤੇ ਜਨਰਲ ਟਿੱਪਣੀਆਂ
• ਇੱਕ Change Request ਕਾਰਵਾਈ ਜੋ ਮਨਜ਼ੂਰੀ ਨੂੰ ਰੋਕਦਾ ਜਦ ਤੱਕ ਮੁੱਦੇ ਹੱਲ ਨਾ ਹੋਣ
• ਟਾਸਕ ਅਸਾਈਨਮੈਂਟ (ਕੌਣ ਕੀ ਕਰੇਗਾ) ਨਾਲ ਮਿਆਦਾਂ ਅਤੇ ਸਧਾਰਨ ਚੈਕਲਿਸਟ

ਇਸ ਨਾਲ ਸਮੀਖਿਆ ਇਕ ਟੂ-ਡੂ ਫਲੋ ਬਣ ਜਾਂਦੀ ਹੈ ਨਾ ਕਿ ਈਮੇਲ ਥਰੇਡ।

SLA ਅਤੇ ਯਾਦਦਿਹਾਨੀਆਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸਮੀਖਿਆ ਨਹੀਂ ਫਸਦੀ

ਫਸੇ ਹੋਏ ਸਮੀਖਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਵਰਕਫਲੋ ਡਿਜ਼ਾਈਨ ਸਮੱਸਿਆ ਹੁੰਦੇ ਹਨ। ਸ਼ਾਮਲ ਕਰੋ:

• ਪ੍ਰਤੀ ਕਦਮ ਵਿਕਲਪਕ SLA (ਉਦਾਹਰਨ: "ਕਾਨੂੰਨੀ ਸਮੀਖਿਆ 5 ਕਾਰੋਬਾਰੀ ਦਿਨਾਂ ਵਿੱਚ")
• ਆਟੋ ਯਾਦਦਿਹਾਨੀਆਂ (ਅਨੁਮੋਦਕਾਂ ਲਈ ਨੱਜ, ਬਦਲਾਅ ਮੰਗੇ ਜਾਣ 'ਤੇ ਲੇਖਕ ਲਈ ਨੱਜ)
• ਇੱਕ ਐਸਕਲੇਸ਼ਨ ਰਾਹ (ਬੈਕਅਪ ਅਨੁਮੋਦਕ ਜਾਂ ਨੀਤੀ ਮਾਲਕ ਨੂੰ ਸੂਚਿਤ)

ਯਾਦਦਿਹਾਨੀਆਂ ਨੂੰ ਸਪੱਸ਼ਟ "ਤੁਸੀਂ ਇਹ ਕਿਉਂ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹੋ" ਸੁਨੇਹਾ ਦੇ ਕੇ ਜੋੜੋ ਅਤੇ ਇੱਕ-ਕਲਿੱਕ ਰਾਹ ਮੁੜ ਓਥੇ ਜਾਉ।

ਸਥਿਤੀ ਅਨਭੁਤਿ ਨੂੰ ਅਸਪਸ਼ਟ ਨਾ ਛੱਡੋ

ਹਰ ਨੀਤੀ ਪੰਨੇ 'ਤੇ ਦਿਖਾਈ deve: ਮੌਜੂਦਾ ਸਥਿਤੀ, ਮੌਜੂਦਾ ਕਦਮ, ਕੌਣ ਇੰਤਜ਼ਾਰ ਕਰ ਰਿਹਾ, ਕੀ ਰੁਕਾਵਟ ਹੈ, ਅਤੇ ਦਰਸ਼ਕ ਲਈ ਅਗਲਾ ਉਪਲਬਧ ਕਾਰਵਾਈ। ਜੇ ਕੋਈ ਪੰਜ ਸਿਕਿੰਟ ਵਿੱਚ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ, ਤਾਂ ਵਰਕਫਲੋ ਚੈਟ/ਈਮੇਲ ਵਿੱਚ ਗਲਤ ਹੋ ਜਾਵੇਗਾ।

ਆਡਿਟ ਟਰੇਲ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਸਬੂਤ

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

ਕੀ ਲੌਗ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਅਤੇ ਕਿੰਨਾ ਵਿਸਤ੍ਰਿਤ)

ਹਰੇਕ ਪ੍ਰਭਾਵਸ਼ाली ਕਾਰਵਾਈ 'ਤੇ ਪੂਰਾ, ਘਟਨਾ-ਅਧਾਰਤ ਆਡਿਟ ਲਾਗ ਐਂਟਰੀ ਲੱਖੋ:

• ਅਭਿਨੇਤਾ: ਯੂਜ਼ਰ ID, ਡਿਸਪਲੇ ਨਾਂ, ਉਸ ਸਮੇਂ ਦਾ ਰੋਲ, ਅਤੇ (ਚਾਹੇ ਤਾਂ) ਵਿਭਾਗ
• ਕਿਰਿਆ: ਬਣਾਇਆ, ਸੋਧਿਆ, ਸਮੀਖਿਆ ਲਈ ਭੇਜਿਆ, ਮਨਜ਼ੂਰ, ਰੱਦ, ਪ੍ਰਕਾਸ਼ਿਤ, ਆਦਿ
• ਟਾਈਮਸਟੈਂਪ: UTC ਵਿੱਚ ਸਟੋਰ, ਯੂਜ਼ਰ ਟਾਈਮਜ਼ੋਨ 'ਚ ਦਿਖਾਓ
• ਵਸਤੂ: ਨੀਤੀ ID, ਵਰਜ਼ਨ ਨੰਬਰ, ਸੈਕਸ਼ਨ, ਅਟੈਚਮੈਂਟ ID, ਟਿੱਪਣੀ ID
• ਪਹਿਲਾਂ/ਬਾਅਦ: ਬਦਲੇ ਹੋਏ ਖੇਤਰਾਂ (ਸਿਰਲੇਖ, ਮਾਲਕ, ਸਥਿਤੀ) ਦੇ ਡਿਫ਼ ਜਾਂ ਸਨੈਪਸ਼ਾਟ

ਇਸ ਨਾਲ ਤੁਸੀਂ ਇਤਿਹਾਸ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਯੋਗ ਹੋ ਜਾਉਗੇ ਬਿਨਾਂ ਮੈਮੋਰੀ ਜਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ 'ਤੇ ਨਿਰਭਰ ਹੋਏ।

ਫੈਸਲਿਆਂ ਅਤੇ ਕਾਰਨ ਨੂੰ ਕੈਪਚਰ ਕਰਨਾ

ਮਨਜ਼ੂਰੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਸਬੂਤ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:

• ਫੈਸਲਾ (approved/rejected) ਅਤੇ ਕਿਸ ਨੇ ਕੀਤਾ
• ਸੰਦਰਭ ਲਈ ਨੋਟਸ (ਕਿਉਂ ਮਨਜ਼ੂਰ ਕੀਤਾ)
• ਰੱਦ ਕਰਨ ਦੇ ਕਾਰਨ (ਲਾਜ਼ਮੀ ਖੇਤਰ ਹੋ ਸਕਦਾ ਹੈ)
• ਵਿਕਲਪਕ: ਸਮੀਖਿਆਕਾਰ ਚੈੱਕਲਿਸਟ ਪੂਰਨਤਾ, ਸਹਾਇਕ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਹਵਾਲੇ

ਸਮੀਖਿਆਕਾਰ ਟਿੱਪਣੀਆਂ ਅਤੇ ਫੈਸਲਾ ਨੋਟਸ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਨੀਤੀ ਵਰਜ਼ਨ ਨਾਲ ਜੁੜੇ ਪਹਿਲੇ ਦਰਜੇ ਦੇ ਰਿਕਾਰਡ ਵਜੋਂ ਰੱਖੋ।

ਲਾਗਜ਼ ਨੂੰ ਛੇੜਛਾੜ-ਪ੍ਰਤੀਕਸ਼ਮ ਬਣਾਉਣਾ

ਚਾਹੇ ਤੁਸੀਂ ਐਡਮਿਨ ਤੇ ਭਰੋਸਾ ਕਰੋ, ਆਡੀਟਰ ਪੁੱਛਣਗੇ ਕਿ ਤੁਸੀਂ "ਚੁਪਕਿਆਂ ਸੋਧਾਂ" ਨੂੰ ਕਿਵੇਂ ਰੋਕਦੇ ਹੋ। ਪ੍ਰਯੋਗਕਰਤਾ ਵਿਧੀਆਂ:

• ਜੋੜਨ-ਕੇਵਲ ਆਡਿਟ ਰਿਕਾਰਡ (ਐਪ ਰਾਹੀਂ ਅਪਡੇਟ/ਡਿਲੀਟ ਬੰਦ)
• ਡਾਇਰੈਕਟ ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਨੂੰ ਸੀਮਿਤ ਕਰੋ ਅਤੇ ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ ਨੂੰ ਵੱਖ-ਰੇਖਾ ਵਿੱਚ ਲਾਗ ਕਰੋ
• ਵਿਚਾਰ ਕਰੋ ਹੈਸ਼ ਚੇਨਿੰਗ (ਹਰੇਕ ਘਟਨਾ ਦਾ ਹੈਸ਼ ਅਤੇ ਪਿਛਲੇ ਹੈਸ਼ ਸਟੋਰ) ਤਾਂ ਜੋ ਬਦਲਾਅ ਪਤਾ ਲੱਗ ਸਕਣ

ਐਕਸਪੋਰਟ ਜੋ ਸੈਂਸੀਟਿਵ ਡੇਟਾ ਲੀਕ ਨਾ ਕਰੇ

ਆਡੀਟਰ ਅਕਸਰ ਆਫਲਾਈਨ ਸਬੂਤ ਚਾਹੁੰਦੇ ਹਨ। ਐਕਸਪੋਰਟ ਪ੍ਰਦਾਨ ਕਰੋ ਜਿਵੇਂ CSV (ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ) ਅਤੇ PDF (ਫਾਈਲਿੰਗ ਲਈ), ਰੈਡੈਕਸ਼ਨ ਨਿਯੰਤਰਣਾਂ ਨਾਲ:

• ਰੋਲ-ਅਧਾਰਿਤ ਏਕਸਪੋਰਟ ਅਧਿਕਾਰ
• ਸੰਵੇਦਨਸ਼ੀਲ ਖੇਤਰਾਂ (ਅੰਦਰੂਨੀ ਨੋਟਸ, ਨਿੱਜੀ ਡੇਟਾ) ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਦਾ ਵਿਕਲਪ
• ਨੀਤੀ ID, ਵਰਜ਼ਨ, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਫੈਸਲਾ ਇਤਿਹਾਸ ਸ਼ਾਮਲ ਹੋ

ਰਿਕਾਰਡ ਰੱਖਣ ਦੀ ਨੀਤੀ

ਰਿਕਾਰਡ ਕਿਸਮ-ਅਨੁਸਾਰ ਰਿਟੇਨਸ਼ਨ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਆਡਿਟ ਘਟਨਾਵਾਂ, ਮਨਜ਼ੂਰੀਆਂ, ਅਟੈਸਟੇਸ਼ਨ ਅਤੇ ਆਰਕੀਵਡ ਨੀਤੀ ਵਰਜ਼ਨ। ਡੀਫ਼ੌਲਟ ਲੋਕਲ ਲੋੜਾਂ ਦੇ ਅਨੁਕੂਲ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਾਫ਼ ਦਸਤਾਵੇਜ਼ ਕਰੋ (ਉਦਾਹਰਨ: ਮਨਜ਼ੂਰੀ ਸਬੂਤ ਡਰਾਫਟ ਸੋਧਾਂ ਨਾਲੋਂ ਲੰਮਾ ਰੱਖੋ)।

ਪ੍ਰਕਾਸ਼ਨ, ਵੰਡ, ਅਤੇ ਅਟੈਸਟੇਸ਼ਨ

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

ਕੰਪਨੀ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮੇਲ ਖਾਣ ਵਾਲੇ ਵੰਡ ਨਿਯਮ

ਇਕ-ਸਾਈਜ਼-ਫਿਟ-ਸਾਰੇ ਨੋ-ਜੋੜੋ। ਐਡਮਿਨ ਨੂੰ ਨੀਤੀ ਵੰਡ ਨਿਯਮ ਗਰੁੱਪ, ਵਿਭਾਗ, ਰੋਲ, ਟਿਕਾਣਾ/ਖੇਤਰ ਜਾਂ ਇਸਦਾ ਸੰਯੋਗ ਦਰਜ ਕਰਨ ਦਿਓ (ਉਦਾਹਰਨ: "ਸਾਰੇ EU ਕਰਮਚਾਰੀ" ਜਾਂ "Engineering + Contractors")। ਨਿਯਮ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਟੈਸਟਯੋਗ ਰੱਖੋ: ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਦਿਖਾਓ ਕਿ ਕੌਣ ਨੀਤੀ ਪ੍ਰਾਪਤ ਕਰੇਗਾ ਅਤੇ ਕਿਉਂ।

ਸੂਚਨਾਵਾਂ: ਲੋਕਾਂ ਤੱਕ ਉਹਥੇ ਪਹੁੰਚੋ ਜਿੱਥੇ ਉਹ ਹਨ

ਸ਼ੁਰੂ ਤੋਂ ਦਿਨ ਇੱਕ ਲਈ ਈਮੇਲ ਅਤੇ ਇਨ-ਐਪ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਪੋਰਟ ਕਰੋ। ਚੈਟ ਨੋਟੀਫਿਕੇਸ਼ਨ (Slack/Teams) ਬਾਅਦ ਵਿੱਚ ਆ ਸਕਦੇ ਹਨ, ਪਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰੋ ਕਿ ਚੈਨਲ ਪਲੱਗਇਬਲ ਹੋਣ।

ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਾਰਵਾਈਯੋਗ ਬਣਾਓ: ਨੀਤੀ ਸਿਰਲੇਖ, ਡਿਊ ਡੇਟ, ਅੰਦਾਜ਼ੀ ਪੜ੍ਹਨ ਸਮਾਂ (ਵਿਕਲਪਕ), ਅਤੇ ਅਟੈਸਟੇਸ਼ਨ ਸਕਰੀਨ ਵੱਲ ਸਿੱਧਾ ਲਿੰਕ ਸ਼ਾਮਲ ਕਰੋ।

ਅਟੈਸਟੇਸ਼ਨ: ਡਿਊ ਡੇਟ, ਯਾਦਦਿਹਾਨੀਆਂ, ਅਤੇ ਐਸਕਲੇਸ਼ਨ

ਹਰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਸਪਸ਼ਟ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: “ਤਾਰੀਖ \u003cdate\u003e ਤੱਕ ਪੜ੍ਹੋ ਅਤੇ ਸਵੀਕਾਰ ਕਰੋ।” ਅਸਾਈਨਮੈਂਟ 'ਤੇ ਡਿਊ ਡੇਟ ਸਟੋਰ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਨੀਤੀ 'ਤੇ।

ਯਾਦਦਿਹਾਨੀਆਂ ਆਟੋ ਕਰੋ (ਉਦਾਹਰਨ: 7 ਦਿਨ ਪਹਿਲਾਂ, 2 ਦਿਨ ਪਹਿਲਾਂ, ਡਿਊ ਡੇਟ ਤੇ, ਅਤੇ ਓਵਰਡਿਊ)। ਐਸਕਲੇਸ਼ਨ ਰਾਹ ਜੋ ਪ੍ਰਬੰਧਕੀ ਸੰਰਚਨਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: X ਦਿਨ ਬਾਅਦ ਬਕਾਇਆ ਹੋਣ 'ਤੇ, ਕਰਮਚਾਰੀ ਦੇ ਮੈਨੇਜਰ ਜਾਂ ਕੰਪਲਾਇੰਸ ਮਾਲਕ ਨੂੰ ਸੂਚਿਤ ਕਰੋ।

ਕਰਮਚਾਰੀ ਦਾ ਦ੍ਰਿਸ਼: “ਮੇਰੀਆਂ ਲਾਜ਼ਮੀ ਨੀਤੀਆਂ”

ਹਰੇਕ ਯੂਜ਼ਰ ਨੂੰ ਸਧਾਰਣ ਡੈਸ਼ਬੋਰਡ ਦਿਓ:

• ਮੇਰੀਆਂ ਲਾਜ਼ਮੀ ਨੀਤੀਆਂ (ਬਕਾਇਆ, ਜਲਦੀ-ਲੱਗਦੀਆਂ, ਓਵਰਡਿਊ)
• ਪੂਰੀਆਂ (ਪੂਰਨਤਾ ਤਾਰੀਖ ਸਮੇਤ)

ਇਹ ਦ੍ਰਿਸ਼ ਅਪਨਾਉਣ ਚਲਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੰਪਲੀਅੰਸ ਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਬਣਾਉਂਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਖੋਜ-ਅਭਿਆਨ।

ਖੋਜਯੋਗਤਾ ਅਤੇ ਅਪਨਾਉਣ ਲਈ UX

ਏਕ ਕੇਂਦਰੀ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਐਪ ਤਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਸਹੀ ਨੀਤੀ ਲੱਭ ਸਕਣ, ਜੋ ਉਹ ਪੜ੍ਹ ਰਹੇ ਹਨ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਣ, ਅਤੇ ਲਾਜ਼ਮੀ ਕਾਰਵਾਈਆਂ (ਜਿਵੇਂ ਸਵੀਕਾਰ) ਬਿਨਾ ਰੁਕਾਵਟ ਦੇ ਕਰ ਸਕਣ। UX ਫੈਸਲੇ ਸਿੱਧਾ ਕੰਪਲਾਇੰਸ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।

ਜਾਣਕਾਰੀ ਆਰਕੀਟੈਕਚਰ ਜੋ ਲੋਕਾਂ ਦੀ ਖੋਜ ਨਾਲ ਮੈਚ ਕਰਦੀ ਹੈ

ਆਰੰਭ ਵਿੱਚ ਇੱਕ ਸਾਫ਼ ਨੀਤੀ ਲਾਇਬ੍ਰੇਰੀ ਪੰਨਾ ਦੇਵੋ ਜੋ ਕਈ ਮਨਸਿਕ ਮਾਡਲਾਂ ਨੂੰ ਸਹਾਰਦਾ:

• ਸ਼੍ਰੇਣੀਆਂ (Security, HR, Finance), ਨਾਲ ਹੀ ਵਿਕਲਪਕ ਟੈਗਸ ("remote work", "vendors")
• ਫਿਲਟਰ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹਨ: ਵਿਭਾਗ, ਖੇਤਰ, ਦਰਸ਼ਕ, ਸਥਿਤੀ (published/archived), ਪ੍ਰਭਾਵੀ ਮਿਤੀ
• ਸੇਵ ਕੀਤਾ ਖੋਜ ਅਤੇ “ਹਾਲੀਆ ਵੇਖਿਆ” ਤਾਂ ਕਿ ਕਰਮਚਾਰੀ ਹਰ ਤਿਮਾਹੀ ਵਿੱਚ ਦੁਬਾਰਾ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਖੋਜ ਨਾ ਕਰਨ

ਖੋਜ ਜੋ ਸਚਮੁੱਚ ਭਾਸ਼ਾ ਸਮਝੇ

ਖੋਜ ਤੇਜ਼ ਅਤੇ ਉਦਾਰ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਦੋ ਫੀਚਰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮੈਟੇਰ ਕਰਦੇ ਹਨ:

• ਰਿਜਲਟ ਵਿੱਚ ਹਾਈਲਾਈਟਸ (ਮੈਚ ਹੋਈ ਵਾਕ ਦਿਖਾਓ, ਸਿਰਫ਼ ਸਿਰਲੇਖ ਨਹੀਂ)
• ਸਿਨੋਨਿਮ ਅਤੇ ਅਕਰੋਨੀਮਜ਼, ਤਾਂ कि "MFA" "multi-factor authentication" ਨੂੰ ਲਭੇ, ਅਤੇ "PII" "personal data" ਨੂੰ ਲਭੇ। ਇਕ ਹਲਕਾ-ਭਾਰ ਸਿਨੋਨਿਮ ਸੂਚੀ ਐਡਮਿਨ ਦੇ ਨਾਲ ਸੰਪਾਦੀਤਾ ਹੋਵੇ।

ਪੜ੍ਹਨ ਯੋਗ ਨੀਤੀ ਪੰਨੇ ਜੋ ਲੋਕ ਸਕੈਨ ਕਰ ਸਕਣ

ਨੀਤੀਆਂ ਲੰਬੀਆਂ ਹੁੰਦੀਆਂ ਹਨ; ਪੜ੍ਹਨ UX ਸ਼੍ਰਮ ਘਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਆਟੋ ਜਨਰੇਟ ਕੀਤਾ ਸਮੱਗਰੀ ਦੀ ਸੂਚੀ ਜਿਸ ਨਾਲ ਹੈੱਡਿੰਗਜ਼ ਨੂੰ ਐਂਕਰ ਕੀਤਾ ਜਾ ਸਕੇ
• ਸੰਬੰਧਿਤ ਨੀਤੀਆਂ (ਉਦਾਹਰਣ: "Password Policy" → "Access Control Standard") ਅਤੇ "last updated" ਮੈਟਾਡੇਟਾ
• ਪਰਿੰਟेबल ਵਿਊ ਆਡੀਟਰਾਂ ਜਾਂ ਆਫਲਾਈਨ ਸਮੀਖਿਆ ਲਈ (ਸਾਫ਼ ਫਾਰਮੇਟਿੰਗ, ਕੋਈ ਨੈਵੀਗੇਸ਼ਨ ਗੰਦਗੀ ਨਹੀਂ)

ਰੁਕਾਵਟ-ਰਹਿਤ ਅਤੇ ਮੋਬਾਈਲ: ਬੁਨਿਆਦੀ ਜ਼ਰੂਰੀਆਂ

ਹਰ ਨੀਤੀ ਪੰਨੇ ਨੂੰ ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ, ਸਹੀ ਹੈਡਿੰਗ ਸਟ੍ਰਕਚਰ, ਅਤੇ ਪਰਿਆਪਤ ਕਾਂਟ੍ਰਾਸਟ ਨਾਲ ਵਰਤੋਗੋ। ਮੋਬਾਈਲ 'ਤੇ, "ਪੜ੍ਹੋ + ਸਵੀਕਾਰ" ਫਲੋ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ: ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ, ਟਿਕਾਵਾਰ ਪ੍ਰਗਤੀ/TOC, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਸਵੀਕਾਰ ਬਟਨ ਜੋ ਛੋਟੀ ਸਕ੍ਰੀਨ 'ਤੇ ਚੰਗਾ ਕੰਮ ਕਰੇ।

ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਟੈਕ ਸਟੈੱਕ ਚੋਇਸਜ਼

ਇੱਕ ਕੇਂਦਰੀ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਐਪ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲਈ ਅਪਰਾਧੀ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਦੀ ਲੋੜ ਨਹੀਂ। লক্ষ ਹੈ ਤੇਜ਼ ਖੋਜ, ਭਰੋਸੇਯੋਗ ਮਨਜ਼ੂਰੀ, ਅਤੇ ਸਾਫ਼ ਆਡਿਟ ਇਤਿਹਾਸ। ਇੱਕ ਸਧਾਰਣ, ਸਮਝਣਯੋਗ ਆਰਕੀਟੈਕਚਰ ਦਿਨ-ਪ੍ਰਤੀ-दਿਨ ਰਖ-ਰਖਾਅ ਵਿੱਚ ਆਮੌਲੀ ਤੌਰ ਤੇ "ਚਲਾਕ" ਹੱਲਾਂ ਤੋਂ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।

ਸਧਾਰਨ ਆਕ੍ਰਿਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਪ੍ਰਯੋਗਕਲਪਨਕ ਡਿਫ਼ਾਲਟ:

• ਵੈੱਬ ਫਰੰਟਐਂਡ ਲੇਖਕਾਂ, ਸਮੀਖਿਆਕਾਰਾਂ, ਅਤੇ ਐਡਮਿਨ ਲਈ
• API (ਜਾਂ ਸਰਵਰ-ਰੇਂਡਰਡ ਐਪ) ਜੋ ਪਰਮਿਸ਼ਨ ਅਤੇ ਵਰਕਫਲੋ ਨਿਯਮ ਲਾਗੂ ਕਰੇ
• ਡੇਟਾਬੇਸ ਨੀਤੀਆਂ, ਵਰਜ਼ਨ, ਮੈਟਾਡੇਟਾ, ਅਤੇ ਘਟਨਾਵਾਂ ਲਈ
• ਖੋਜ ਸਿਰਲੇਖ, ਟੈਗਸ, ਅਤੇ ਫੁੱਲ-ਟੈਕਸਟ ਲਈ ਤੇਜ਼ੀ

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

ਆਪਣੀ ਟੀਮ ਜੋ ਕਾਬੂ ਰੱਖਦੀ ਹੈ ਉਹ “ਬੋਰਿੰਗ” ਸਟੈਕ ਚੁਣੋ

ਉਹ ਟੈਕਨੋਲੋਜੀਆਂ ਚੁਣੋ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਪਹਿਲਾਂ ਤੋਂਸ਼ਿਪ ਕਰਦੀ ਹੈ। ਨਿਰੰਤਰਤਾ ਨੋਵਲਟੀ ਤੋਂ ਜ਼ਿਆਦਾ ਮੈਟੇਰ ਕਰਦੀ ਹੈ।

ਆਮ, ਸੰਭਾਲਯੋਗ ਵਿਕਲਪਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਬੈਕਐਂਡ: Node.js (Express/Nest), Python (Django/FastAPI), ਜਾਂ .NET
• ਫਰੰਟਐਂਡ: React/Vue, ਜਾਂ ਸਰਵਰ-ਰੇਂਡਰਡ ਪੰਨੇ ਜੇ ਟੀਮ ਸਾਦਗੀ ਚਾਹੁੰਦੀ
• ਡੇਟਾਬੇਸ: Postgres ਰਿਲੇਸ਼ਨਲ ਡੇਟਾ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਮਜ਼ਬੂਤ ਡਿਫ਼ਾਲਟ
• ਖੋਜ: ਸ਼ੁਰੂ ਵਿੱਚ Postgres full-text; ਲੋੜ ਹੋਣ 'ਤੇ OpenSearch/Elasticsearch ਜੋੜੋ

ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਡਿਲਿਵਰੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਮੁੜ-ਵਰਤਣਾ ਬਿਨਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ chat ਰਾਹੀਂ ਕੋਰ ਫਲੋਜ਼ (RBAC, ਵਰਕਫਲੋ, ਡੈਸ਼ਬੋਰਡ) ਸਕੈਫੋਲਡ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨ ਲਈ।

ਸਿੰਗਲ-ਟੇਨੈਂਟ vs ਮਲਟੀ-ਟੇਨੈਂਟ ਦਾ ਫੈਸਲਾ ਪਹਿਲਾਂ ਕਰੋ

ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਗ੍ਰਾਹਕ ਨਾਲ ਲਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਤੁਸੀਂ ਭਵਿੱਖ ਵਿੱਚ ਬਹੁਤ ਸੰਗਠਨਾਂ ਨੂੰ ਸਹਾਇਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ:

• ਸਿੰਗਲ-ਟੇਨੈਂਟ: ਡੇਟਾ ਅਲੱਗ ਕਰਨ ਲਈ ਸਹੀ, ਕਸਟਮਾਈਜੇਸ਼ਨ ਅਸਾਨ
• ਮਲਟੀ-ਟੇਨੈਂਟ: ਪ੍ਰਤੀ ਗ੍ਰਾਹਕ ਘੱਟ ਓਪਰੇਸ਼ਨਲ ਲਾਗਤ, ਪਰ ਕੜੀ ਟੇਨੈਂਟ ਆਈਸੋਲੇਸ਼ਨ ਅਤੇ ਅਧਿਕ ਸਾਵਧਾਨੀ

ਜੇ ਮਲਟੀ-ਟੇਨੈਂਟ ਸੰਭਵ ਹੈ, ਤਾਂ ਸਾਰਥਿਕ ID ਅਤੇ ਕੁਐਰੀਆਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ tenant-aware ਬਣਾਓ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਭ ਕੁਝ ਮੁੜ ਨਹੀਂ ਲਿਖਣਾ ਪਵੇ।

ਫਾਈਲ ਸਟੋਰੇਜ ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਾਊਨਲੋਡ

ਨੀਤੀਆਂ ਅਕਸਰ ਅਟੈਚਮੈਂਟ ਰੱਖਦੀਆਂ ਹਨ (PDF, spreadsheet, ਸਬੂਤ)। ਯੋਜਨਾ ਬਣਾਓ:

• ਵਸਤੂ ਸਟੋਰੇਜ (S3-ਸਮਰੂਪ) ਨੂੰ ਡੇਟਾਬੇਸ ਤੋਂ ਵੱਖ ਰੱਖੋ
• ਪਰੈ-ਸਾਈਨਡ, ਸਮੇਂ-ਸੀਮਤ ਡਾਊਨਲੋਡ ਲਿੰਕ ਅਤੇ ਕੜੀ ਐਕਸੈਸ ਚੈੱਕ
• ਵਿਦੇਸ਼ੀ ਅਪਲੋਡ ਉਮੀਦ ਹੋਵੇ ਤਾਂ ਵਾਇਰਸ ਸਕੈਨਿੰਗ ਅਤੇ ਫਾਈਲ-ਟਾਈਪ ਸੀਮਾਵਾਂ

ਪਿਛੋਕੜ ਨੌਕਰੀਆਂ ਉਹ ਕੰਮ ਜੋ ਦਿੱਖ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀਆਂ

ਕੁਝ ਕੰਮ ਯੂਜ਼ਰ-ਕਲਿੱਕ ਦੌਰਾਨ ਨਹੀਂ ਚੱਲਣੇ:

• ਸਮੀਖਿਆ ਅਤੇ ਅਟੈਸਟੇਸ਼ਨ ਲਈ ਯਾਦਦਿਹਾਨੀਆਂ
• ਨਿਯਤ ਐਕਸਪੋਰਟ (PDF ਪੈਕ, ਆਡਿਟ ਬੰਡਲ)
• ਸੋਧਾਂ ਤੋਂ ਬਾਅਦ ਖੋਜ ਇੰਡੈਕਸਿੰਗ

ਇਕ ਸਧਾਰਣ ਕਤਾਰ + ਵਰਕਰ ਸੈਟਅਪ ਐਪ ਨੂੰ ਰਿਸਪਾਂਸਿਵ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇਨ੍ਹਾਂ ਟਾਸਕਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਜੋ ਤੁਹਾਨੂੰ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ

ਸੁਰੱਖਿਆ ਨੂੰ "ਫੇਜ਼ ਦੂਜਾ" ਨਾ ਸਮਝੋ: ਨੀਤੀਆਂ ਅਕਸਰ ਅੰਦਰੂਨੀ ਨਿਯੰਤਰਣ, ਘਟਨਾ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਵੇਂਡਰ ਵੇਰਵੇ ਆਦਿ ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਸਭ ਨੂੰ ਵਿਸ਼ਾਲ ਦਿਖਾਉਣਾ ਨਹੀਂ ਚਾਹੀਦਾ।

ਪ੍ਰਮਾਣਿਕਤਾ: ਸਾਦਾ ਸ਼ੁਰੂ ਕਰੋ, ਬਾਅਦ ਵਿੱਚ SSO ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ

ਜੇ ਤੁਸੀਂ ਦਿਨ ਇੱਕ ਤੇ SSO ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਸੁਰੱਖਿਅਤ ਈਮੇਲ/ਪਾਸਵਰਡ ਫਲੋ ਠੀਕ ਹੈ—ਬਸ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਹੋਵੇ।

• ਪ੍ਰਮਾਣਿਤ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਪਾਸਵਰਡ ਹੈਸ਼ਿੰਗ (Argon2/bcrypt)
• ਲੌਗਿਨ ਕੋਸ਼ਿਸ਼ਾਂ 'ਤੇ ਰੇਟ-ਲਿਮਿਟ
• ਕ੍ਰੈਡੇਂਸ਼ਲ-ਸਟਫਿੰਗ ਦੇ ਖਿਲਾਫ ਰੋਕਥਾਮ

ਆਪਣੇ ਆਈਡੈਂਟੀਟੀ ਲੇਅਰ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ SAML/OIDC ਬਾਅਦ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕੇ।

ਸੰਵੇਦਨਸ਼ੀਲ ਨੀਤੀਆਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ

ਹਰ ਕਰਮਚਾਰੀ ਨੂੰ ਹਰ ਡਰਾਫਟ ਦੇਖਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਡੀਫ਼ੌਲਟ ਨੂੰ "ਕੋई ਪਹੁੰਚ ਨਹੀਂ" ਰੱਖੋ ਅਤੇ ਘੁੱਟ-ਘੱਟ ਅਧਿਕਾਰ ਦੇਵੋ।

ਪ੍ਰਯੋਗਕਲਪਨਕ ਰੱਖੋ:

• ਵਰਕਸਪੇਸ/ਵਿਭਾਗ ਮੈਂਬਰਸ਼ਿਪ ਨਾਲ ਵਿਜ਼ਿਬਿਲਟੀ
• ਸੰਵੇਦਨਸ਼ੀਲ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਪ੍ਰਤੀ-ਨੀਤੀ ਐਕਸੈਸ ਓਵਰਰਾਈਡ
• ਦੇਖੋ, ਟਿੱਪਣੀ, ਸੰਪਾਦਨ, ਅਤੇ ਮਨਜ਼ੂਰੀ ਲਈ ਅਲੱਗ ਅਧਿਕਾਰ

ਇੰ-ਟਰਾਂਜ਼ਿਟ ਅਤੇ ਐੱਟ-ਰੇਸਟ ਇੰਕ੍ਰਿਪਸ਼ਨ

ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਲਈ TLS ਲਾਜ਼ਮੀ ਕਰੋ। ਐੱਟ-ਰੇਸਟ ਤੇ ਇੰਕ੍ਰਿਪਸ਼ਨ ਦੋਨੋਂ ਤੇ ਯੋਜਨਾ ਬਣਾਓ:

• ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਵਾਲਿਊਮ/ਡਿਸਕ ਇੰਕ੍ਰਿਪਟ
• ਅਟੈਚਮੈਂਟਜ਼ ਲਈ ਸਟੋਰੇਜ ਇੰਕ੍ਰਿਪਸ਼ਨ

ਕੀ ਮੈਨੇਜਮੈਂਟ ਲਈ ਯੋਜਨਾ ਬਣਾਓ: ਕੌਣ ਕੀ ਫੜਦਾ/ਰੋਟੇਟ ਕਰਦਾ/ਕੀ ਹਾਲਤ ਰਹਿੰਦੀ ਹੈ।

ਇਨਪੁਟ ਵੈਧਤਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਹੈਂਡਲਿੰਗ

ਹਰ ਫਾਰਮ ਫ਼ੀਲਡ ਅਤੇ ਅਪਲੋਡ ਨੂੰ ਖਤਰਨਾਕ ਸਮਝੋ। ਸਰਵਰ-ਸਾਈਡ ਵੈਧਤਾ ਕਰੋ, ਰਿਚ ਟੈਕਸਟ ਇਨਪੁਟ ਨੂੰ ਸਾਂਨੀਟਾਈਜ਼ ਕਰੋ, ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਵੈਬ ਰੂਟ ਤੋਂ ਬਾਹਰ ਸਟੋਰ ਕਰੋ।

ਅਪਲੋਡ ਲਈ ਟਾਈਪ ਅਤੇ ਸਾਈਜ਼ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰੋ, ਜਿੱਥੇ ਸੰਭਵ ਹੋ ਵਾਇਰਸ ਸਕੈਨ ਕਰੋ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਫ਼ਾਇਲ-ਨਾਮ ਉਤਪੰਨ ਕਰੋ।

ਐਡਮਿਨ ਨਿਯੰਤਰਣ: ਸੈਸ਼ਨ ਸੀਮਿਤ, MFA, ਅਤੇ ਰਿਕਵਰੀ

ਸੈਸ਼ਨ ਟਾਈਮਆਉਟ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਜੋੜੋ (ਜਿਵੇਂ ਅਧਿਕਾਰ ਬਦਲਣਾ)। ਭਾਵੇਂ MFA ਲਾਂਚ 'ਤੇ ਲਾਜ਼ਮੀ ਨਾ ਹੋਵੇ, ਪਰ TOTP ਅਤੇ ਰਿਕਵਰੀ ਕੋਡ ਲਈ ਡਿਜ਼ਾਈਨ ਸ਼ਾਮਲ ਕਰੋ।

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

ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਣਨੀਤੀ

ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਐਪ ਨੂੰ ਤੁਹਾਡੇ ਸੰਗਠਨ ਵਿੱਚ ਨੈਟਿਵ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹਨ—ਪਰ ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਜ਼ਰੂਰੀ ਸਮਝ ਕੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਗਾ ਦਿਓ ਤਾਂ ਡਿਲਿਵਰੀ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਅਰਾਮ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋਏ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕੋ।

ਆਈਡੈਂਟੀਟੀ ਅਤੇ ਐਕਸੈਸ: ਗਰੁੱਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਅਧਿਕਤਰ ਟੀਮਾਂ ਪਹਿਲਾਂ ਹੀ ਆਈਡੈਂਟੀਟੀ ਪ੍ਰੋਵਾਈਡਰ ਵਿੱਚ ਲੋਕਾਂ ਅਤੇ ਅਧਿਕਾਰਾਂ ਨੂੰ ਸਾਂਭਦੀਆਂ ਹਨ। Google Workspace ਅਤੇ Microsoft Entra ID ਲਈ ਕਨੈਕਟਰ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ:

• ਗਰੁੱਪ (ਜਿਵੇਂ "Engineering", "Managers") ਸਿੰਕ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਲ ਨਾਲ ਮੈਪ ਕਰੋ
• ਪਹਿਲੀ ਸਾਈਨ-ਇਨ 'ਤੇ ਯੂਜ਼ਰ ਆਟੋ-ਪ੍ਰੋਵਿਜ਼ਨ
• ਖਾਤਾ নিষਕ੍ਰਿਯ ਹੋਣ 'ਤੇ ਐਕਸੈਸ ਰੋਕੋ

ਸ਼ੁਰੂਆਤ ਲਈ ਸੀਮਤ ਸਕੋਪ ਰੱਖੋ—ਗਰੁੱਪ ਸਿੰਕ ਅਤੇ ਬੇਸਿਕ ਪ੍ਰੋਫਾਈਲ ਫੀਲਡ। ਅਡਵਾਂਸਡ ਨਿਯਮ ਬਾਅਦ ਵਿੱਚ ਆ ਸਕਦੇ ਹਨ।

ਮਾਈਗ੍ਰੇਸ਼ਨ: ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੈ ਉਸਨੂੰ ਇੰਪੋਰਟ ਕਰੋ

ਏਕ ਕੇਂਦਰੀ ਰਿਪੋਜ਼ਟਰੀ ਤਾਂ ਹੀ ਕੰਮ ਕਰੇਗਾ ਜਦ ਤੁਸੀਂ ਮੌਜੂਦਾ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਬਿਨਾਂ ਹੱਥੋਂ-ਹੱਥ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦੇ ਹੋਏ ਲਿਆ ਸਕੋ। ਇਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਫਲੋ ਮੁਹੱਈਆ ਕਰੋ ਜੋ:

• Drive ਅਤੇ SharePoint ਤੋਂ ਇੰਪੋਰਟ ਕਰੇ
• ਕੀੰਨ-ਮੈਟਾਡੇਟਾ ਬਚਾਏ ਜੋ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ (ਸਿਰਲੇਖ, ਆਖ਼ਰੀ ਸੋਧ ਦੀ ਤਾਰੀਖ, ਮਾਲਕ, ਫੋਲਡਰ ਪਾਥ)
• ਐਡਮਿਨ ਨੂੰ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀ ਕਿਸਮ/ਟੈਮਪਲੇਟ ਅਸਾਈਨ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦੇਵੇ

ਗਦਰਲੀ ਫਾਈਲਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ। "Needs attention" ਕਤਾਰ ਬਣਾਓ ਬਜਾਏ ਕਿ ਪੂਰੀ ਇੰਪੋਰਟ ਨੂੰ ਰੋਕਣ ਦੇ।

HR ਅਪਡੇਟ webhook ਜਾਂ API ਰਾਹੀਂ

ਕਰਮਚਾਰੀ ਸਥਿਤੀ ਬਦਲਾਅ ਐਕਸੈਸ ਅਤੇ ਅਟੈਸਟੇਸ਼ਨ ਚਲਾਉਂਦੇ ਹਨ। ਇੱਕ ਸਾਦਾ webhook ਜਾਂ API ਐਂਡਪੌਇੰਟ ਦਿਓ ਤਾਂ ਜੋ HR ਸਿਸਟਮ "employee terminated" ਜਾਂ "department changed" ਵਰਗੇ ਆਪਣੇ ਇਵੈਂਟ ਭੇਜ ਸਕੇ। ਇਹ ਆਟੋਮੈਟਿਕ ਰੋਲ ਅਪਡੇਟ, ਬੇਨਤੀ ਹਟਾਉਣ ਅਤੇ ਮਾਲਕੀ ਬਦਲਣ ਨੂੰ ਟਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ।

GRC ਟੂਲ ਲਈ ਰਿਪੋਰਟਿੰਗ ਐਕਸਪੋਰਟ

ਭਾਵੇਂ ਤੁਸੀਂ ਪਹਿਲਾਂ GRC ਪਲੇਟਫਾਰਮ ਨਾਲ ਸਿੱਧੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨਾ ਕਰੋ, ਰਿਪੋਰਟਿੰਗ ਪੋਰਟੇਬਲ ਬਣਾਓ:

• ਆਡਿਟ ਅਤੇ ਨੀਤੀ-ਸੰਬੰਧੀ ਡੇਟਾ ਲਈ CSV ਐਕਸਪੋਰਟ
• ਨੀਤੀਆਂ, ਵਰਜ਼ਨ, ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਅਟੈਸਟੇਸ਼ਨਾਂ ਲਈ API ਐਂਡਪੌਇੰਟ

ਇਨ੍ਹਾਂ ਨੂੰ /docs/integrations ਹੇਠ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਕਿ ਖਰੀਦਦਾਰ ਜਾਣ ਸਕਣ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਰਿਪੋਰਟਿੰਗ ਵਰਕਫਲੋ ਵਿੱਚ ਫਿੱਟ ਹੋਵੋਗੇ।

MVP ਸਕੋਪ, ਲਾਂਚ ਯੋਜਨਾ, ਅਤੇ ਦੁਹਰਾਈ

ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਵੱਡਾ ਪ੍ਰੋਗਰਾਮ ਬਣ ਸਕਦਾ ਹੈ। ਕੁਝ ਉਪਯੋਗੀ ਚੀਜ਼ ਜਲਦੀ ਭੇਜਣ ਲਈ ਟਾਈਟ MVP ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਜੋ ਪੂਰੇ ਨੀਤੀ ਲਾਈਫਸਾਈਕਲ ਲੂਪ ਦਾ ਸਮਰਥਨ ਕਰੇ: ਬਣਾਉ, ਸਮੀਖਿਆ, ਪ੍ਰਕਾਸ਼ਨ, ਅਟੈਸਟੇਸ਼ਨ, ਅਤੇ ਜੋ ਘਟਿਆ—ਉਸ ਦਾ ਸਬੂਤ ਪੇਸ਼ ਕਰੋ।

ਪ੍ਰਯੋਗਕਲਪਨਕ MVP (ਕੀ ਜਰੂਰੀ ਹੋ ਕੇ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ)

ਤੁਹਾਡਾ MVP ਕੋਰ "ਹੈਪੀ ਪਾਥ" ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

• ਨੀਤੀ ਲਾਇਬ੍ਰੇਰੀ (ਰਿਪੋਜ਼ਟਰੀ): ਇੱਕ ਥਾਂ ਨੀਤੀਆਂ ਸਾਫ਼ ਸ਼੍ਰੇਣੀ, ਮਾਲਕ ਅਤੇ ਸਥਿਤੀ ਨਾਲ
• ਨੀਤੀ ਵਰਜ਼ਨ ਕੰਟਰੋਲ: ਅਟੁੱਟ ਵਰਜ਼ਨ, ਪੜ੍ਹਨਯੋਗ ਬਦਲਾਅ ਸਾਰ, ਵਰਜ਼ਨਾਂ ਦੀ ਤੁਲਨਾ
• ਨੀਤੀ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ: Draft → Review → Approval RBAC ਨਾਲ
• ਪ੍ਰਕਾਸ਼ਨ: ਵਿਸ਼ਵਾਸਯੋਗ "ਕਰੰਟ ਪ੍ਰਭਾਵੀ ਵਰਜ਼ਨ" ਦ੍ਰਿਸ਼
• ਨੀਤੀ ਵੰਡ ਅਤੇ ਅਟੈਸਟੇਸ਼ਨ: ਗਰੁੱਪਾਂ ਨੂੰ ਅਸਾਈਨ ਕਰਨਾ, ਸਵੀਕਾਰਤਾਵਾਂ ਇਕੱਠੀਆਂ ਕਰਨਾ, ਬਕਾਇਆ ਟਰੈਕ ਕਰਨਾ
• ਨੀਤੀ ਆਡਿਟ ਟਰੇਲ: ਕਿਸ ਨੇ ਕੀ ਬਦਲਿਆ, ਕਿਸ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ, ਅਤੇ ਕਿਸ ਨੇ ਸਵੀਕਾਰ ਕੀਤਾ—ਤਾਰੀਖ ਸਮੇਤ

ਟੈਮਪਲੇਟ ਅਤੇ ਉੱਨਤ ਆਟੋਮੇਸ਼ਨ ਬਾਅਦ ਲਈ ਛੱਡੋ। ਤੁਸੀਂ ਸ਼ੁਰੂਆਤੀ ਕੁਝ ਨੀਤੀ ਟੈਮਪਲੇਟ ਵੀ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿ ਸੂਣੇ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਿਆਂ ਦੀ ਰੁਕਾਵਟ ਘਟ ਜਾਵੇ।

ਜੇ ਤੁਸੀਂ ਇਹ ਇਨ-ਹਾਊਸ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ ਸਹਾਰਾ ਸੋਚੋ: ਤੁਸੀਂ ਵਰਕਫਲੋ ਦਾ ਵਰਣਨ (ਸਥਿਤੀਆਂ, ਮਨਜ਼ੂਰੀਆਂ, ਅਟੈਸਟੇਸ਼ਨ, ਆਡਿਟ ਲਾਗ) ਚੈਟ ਵਿੱਚ ਦੇ ਸਕਦੇ ਹੋ, ਤੇਜ਼ੀ ਨਾਲ ਅਦਲਾ-ਬਦਲੀ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਲੰਬੇ ਸਮੇਂ ਦੀ ਮਲਕੀਅਤ ਲਈ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।

ਵਾਤਾਵਰਨ ਅਤੇ ਮੂਲ CI/CD ਸੈੱਟਅਪ

ਸ਼ੁਰੂ ਤੋਂ ਤਿੰਨ ਵਾਤਾਵਰਨ ਰੱਖੋ: dev, staging, ਅਤੇ production। Staging production ਨਾਲ ਪਰਯਾਪਤ ਮਿਲਦੀ-ਜੁਲਦੀ ਹੋਵੇ ਤਾਂ ਕਿ ਪਰਮਿਸ਼ਨ, ਵਰਕਫਲੋ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਫਲੋ ਚੈੱਕ ਹੋ ਸਕਣ।

CI/CD ਲਈ ਸਧਾਰਣ ਗੋਲ:

• ਹਰ merge 'ਤੇ ਆਟੋਮੈਟਿਕ ਟੈਸਟ
• ਸਟੇਜਿੰਗ 'ਤੇ ਇਕ-ਕਲਿੱਕ ਡਿਪਲੋ
• production 'ਤੇ ਗੇਟਡ ਡਿਪਲੋ (ਸ਼ੁਰੂ 'ਚ ਮੈਨੂਅਲ ਮਨਜ਼ੂਰੀ ਠੀਕ)

ਨਿਗਰਾਨੀ ਅਤੇ ਵਰਤੋਂ ਮੈਟ੍ਰਿਕਸ ਜੋ ਗੱਲ ਕਰਦੇ ਹਨ

ਤੁਹਾਨੂੰ ਇੱਕ ਕੰਪਲੀਕੇਟੇਡ ਓਬਜ਼ਰਵੇਬਿਲਿਟੀ ਸਟੈਕ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਜਦ ਕੁਝ ਟੁੱਟੇ ਤਾਂ ਜਵਾਬ ਦੇਣ ਲਈ ਅੰਕੜੇ ਚਾਹੀਦੇ ਹਨ। ਟਰੈਕ ਕਰੋ:

• ਉਪਟਾਈਮ ਅਤੇ ਮੂਲ ਪ੍ਰਤੀਕਿਰਿਆ ਸਮਾਂ
• ਏਰਰ ਟ੍ਰੈਕਿੰਗ (ਬੈਕਐਂਡ ਐਕਸੈਪਸ਼ਨ ਅਤੇ ਫਰੰਟਐਂਡ ਕ੍ਰੈਸ਼)
• ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ: ਪ੍ਰਤੀ ਮਹੀਨਾ ਪ੍ਰਕਾਸ਼ਿਤ ਨੀਤੀਆਂ, ਔਸਤ ਸਮੀਖਿਆ ਸਮਾਂ, ਅਟੈਸਟੇਸ਼ਨ ਪੂਰਨਤਾ ਦਰ, ਅਤੇ ਖੋਜ ਕਵੈਰੀਆਂ ਜਿਨ੍ਹਾਂ ਦੇ ਨਤੀਜੇ ਖਾਲੀ ਆਉਂਦੇ ਹਨ

ਇਹ ਮੈਟ੍ਰਿਕਸ ਦੱਸਣਗੇ ਕਿ ਅਪਨਾਉਣ ਕਿੱਥੇ ਫੇਲ ਹੋ ਰਿਹਾ—ਖੋਜਯੋਗਤਾ, ਵਰਕਫਲੋ ਬੋਟਲਨੈਕ, ਜਾਂ ਅਸਪਸ਼ਟ ਮਾਲਕੀ।

ਰੋਲਆਉਟ ਯੋਜਨਾ ਅਤੇ ਨੀਤੀ ਮਾਲਕਾਂ ਲਈ ਪ੍ਰਸ਼ਿਕਸ਼ਣ

ਇੱਕ ਪਾਇਲਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਛੋਟੇ, ਟਾਸਕ-ਅਧਾਰਿਤ ਮੈਟਰੀਅਲ ਦਿਓ:

• “ਕਿਵੇਂ ਨੀਤੀ ਬਣਾਈਏ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਭੇਜੋ”
• “ਕਿਵੇਂ ਮਨਜ਼ੂਰ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ”
• “ਕਿਵੇਂ ਅਟੈਸਟੇਸ਼ਨ ਅਸਾਈਨ ਅਤੇ ਫਾਲੋਅਪ ਕਰੋ”

ਹਰ ਨੀਤੀ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਨਿਰਧਾਰਿਤ ਮਾਲਕ ਅਤੇ ਬੈਕਅਪ ਮਾਲਕ ਹੋਣ ਜ਼ਰੂਰੀ ਹੈ।

ਪ੍ਰਤੀਕਿਰਿਆ 'ਤੇ ਅਧਾਰਿਤ ਦੁਹਰਾਈ

ਲਾਂਚ ਬਾਅਦ, ਉਸ ਸੁਧਾਰ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ ਜੋ ਦੁਹਰਾਈ ਦੁਆਰਾ ਆ ਰਹੀਆਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਦੂਰ ਕਰੇ:

• ਖੋਜ ਅਤੇ ਫਿਲਟਰਾਂ 'ਚ ਸੁਧਾਰ
• ਹੋਰ ਟੈਮਪਲੇਟ ਅਤੇ ਸੰਰਚਿਤ ਮੈਟਾਡੇਟਾ
• ਮਾਲਕਾਂ ਅਤੇ ਕੰਪਲਾਇੰਸ ਟੀਮਾਂ ਲਈ ਹਲਕੀ-ਫੁਟਕਿ ਐਨਾਲੇਟਿਕਸ
• ਅਤਿਰਿਕਤ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (HRIS ਗਰੁੱਪ, SSO, ਟਿਕਟਿੰਗ, e-sign)

ਜੇ ਤੁਸੀਂ MVP ਨੂੰ accountability ਅਤੇ proof—ਯਾਨੀ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ + ਆਡਿਟ ਟਰੇਲ + ਅਟੈਸਟੇਸ਼ਨ—'ਤੇ ਕੇਂਦਰਤ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਕੰਪਲੀਅੰਸ ਯੋਗ ਰਿਪੋਜ਼ਟਰੀ ਹੋਵੇਗਾ ਜੋ ਦਿਨ-ਪ੍ਰਤੀ ਦਿਨ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।