ਡਾਟਾ ਨੁਕਸਾਨ ਰੋਕਣ ਵਾਲੇ ਐਡਮਿਨ ਟੂਲ: ਸੁਰੱਖਿਅਤ ਬਲਕ ਐਕਸ਼ਨ

ਜਿੱਥੇ ਐਡਮਿਨ ਟੂਲਾਂ ਵਿੱਚ ਡਾਟਾ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ

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

ਜ਼ਿਆਦਾਤਰ ਹਾਦਸੇ ਦੁਰਨੈਤ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ "ਊਪਸ" ਪਲਾਂ ਤੋਂ ਹੁੰਦੇ ਹਨ: ਫਿਲਟਰ ਬਹੁਤ ਵਿਆਪਕ ਰਹਿ ਗਿਆ, ਖੋਜ ਸ਼ਬਦ ਆਸ਼ਾ ਤੋਂ ਵੱਧ ਮਿਲ ਗਿਆ, ਜਾਂ ਡ੍ਰੌਪਡਾਊਨ ਗਲਤ ਟੇਨੈਂਟ 'ਤੇ ਰਹਿ ਗਿਆ। ਇੱਕ ਹੋਰ ਆਮ ਗਲਤੀ ਗਲਤ ਵਾਤਾਵਰਣ ਹੈ: ਕੋਈ ਸੋਚਦਾ ਹੈ ਕਿ ਉਹ staging ਵਿੱਚ ਹੈ, ਪਰ UI ਲਗਭਗ ਇੱਕੋ ਜਿਹਾ ਹੋਣ ਕਾਰਨ ਉਹ production ਵੇਖ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

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

“ਡਾਟਾ ਨਸ਼ਟ ਕਰਨਾ” ਸਿਰਫ਼ ਡਿਲੀਟ ਬਟਨ ਦਬਾਉਣਾ ਨਹੀਂ ਹੈ। ਅਮਲ ਵਿੱਚ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:

• ਰਿਕਾਰਡ ਹਟਾਉਣਾ (ਕੈਸਕੇਡਿੰਗ ਡਿਲੀਟ ਸਮੇਤ)
• ਫੀਲਡਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨਾ (ਜਿਵੇਂ ਕਿ ਗਲਤ ਸੈੱਟ ਲਈ status ਨੂੰ “closed” ਕਰਨਾ)
• ਰਿਸ਼ਤੇ ਨੂੰ ਕੱਟਣਾ (ਯੂਜ਼ਰ ਨੂੰ ਖਾਤੇ ਤੋਂ ਅਨਲਿੰਕ ਕਰਨਾ, ਅਧਿਕਾਰ ਹਟਾਉਣਾ)
• ਇਤਿਹਾਸ ਮਿਟਾਉਣਾ (ਲੌਗ ਸਾਫ਼ ਕਰਨਾ, ਸੁਨੇਹੇ ਮਿਟਾਉਣਾ, ਟੇਬਲ ਟਰੰਕੇਟ)
• ਅਪਰਿਵਰਤਨੀਯ ਨਿਰਯਾਤ ਜਾਂ ਸਿੰਕ (ਗਲਤ ਡੇਟਾ ਨੂੰ ਦੂਜੇ ਸਿਸਟਮ ਵਿੱਚ ਧੱਕਨਾ)

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

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਐਪ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਖਤਰੇ ਵਹੀ ਰਹਿੰਦੇ ਹਨ। ਫ਼ਰਕ ਇਸ ਗੱਲ ਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਗਾਰਡਰੇਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਜਾਂ ਪਹਿਲੀ ਘਟਨਾ ਦੇ ਬਾਅਦ ਸਿੱਖਦੇ ਹੋ।

ਇੱਕ ਸਧਾਰਨ ਰਿਸਕ ਮੈਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਰੋਜ਼ਾਨਾ ਐਡਿਟਸ ਨਹੀਂ ਹੁੰਦੀਆਂ; ਇਹ ਉਹ ਆਪਰੇਸ਼ਨ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡ ਪਰੇਟਕਰਦੇ ਹਨ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਛੂਹਦੇ ਹਨ।

ਇੱਕ ਮਦਦਗਾਰ ਪਹਿਲਾ ਪਾਸ ਇਹ ਹੈ:

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

ਫਿਰ ਹਰ ਕਾਰਵਾਈ ਨੂੰ ਰਿਵਰਸਿਬਲ ਜਾਂ ਅਪਰੀਵਰਟਨੀਯ ਵਜੋਂ ਨਿਸ਼ਾਨ ਲਗਾਓ। ਸਖ਼ਤ ਰਹੋ। ਜੇ ਤੁਸੀਂ ਮਾਤਰ ਬੈਕਅੱਪ ਤੋਂ ਰਿਪੇਅਰ ਕਰਕੇ ਹੀ ਸਹੀ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਓਪਰੇਟਰ ਲਈ ਅਪਰੀਵਰਟਨੀਯ ਸਿਰਫ਼ ਮਾਨੋ।

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

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

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

ਉਦਾਹਰਨ: Koder.ai 'ਤੇ ਇਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਤੁਸੀਂ “ਬਲਕ ਇੰਪੋਰਟ ਯੂਜ਼ਰ” ਨੂੰ ਬਹੁ-ਰਿਕਾਰਡ, ਬਹਾਲੀ ਜੋ ਲਾਗ-ਇਡੀਟੀ ਲਿਖਦੇ ਹੋਵੋ ਤਾਂ ਹੀ ਵਾਪਸੀਯੋਗ, ਅਤੇ ਨੀਤੀ-ਸੁਰੱਖਿਅਤ ਕਿਉਂਕਿ ਇਹ PII ਵਿੱਚ ਛੇੜछਾੜ ਕਰਦਾ ਹੈ, ਵਜੋਂ ਟੈਗ ਕਰ ਸਕਦੇ ਹੋ।

ਸੁਰੱਖਿਅਤ ਬਲਕ ਐਕਸ਼ਨ ਦੇ ਪੈਟਰਨ

ਬਲਕ ਐਕਸ਼ਨ ਉਸ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਚੰਗੇ ਐਡਮਿਨ ਟੂਲ ਜੋਖ਼ਿਮੀ ਹੋ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਐਡਮਿਨ ਟੂਲ ਬਣਾ ਰਹੇ ਹੋ ਜੋ ਡਾਟਾ ਨੁਕਸਾਨ ਰੋਕਣ, ਤਾਂ ਹਰ “ਬਹੁੱਤ ਤੇ ਲਾਗੂ ਕਰੋ” ਬਟਨ ਨੂੰ ਇੱਕ ਪਾਵਰ ਟੂਲ ਵਾਂਗ سمجھੋ: ਲਾਭਕਾਰੀ, ਪਰ ਗਲਤੀਆਂ ਤੋਂ ਬਚਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਹੋਇਆ।

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

ਸਕੋਪ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਸਮਝਣ-ਯੋਗ ਬਣਾਓ। “ਸਾਰੇ” ਨੂੰ ਇੱਕ ਅਸਪਸ਼ਟ ਵਿਚਾਰ ਨਾ ਮਨ ਲਵੋ। ਓਪਰੇਟਰ ਨੂੰ ਫਿਲਟਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੋ—ਟੇਨੈਂਟ, ਸਥਿਤੀ, ਅਤੇ ਤਾਰੀਖ ਦੀ ਰੇਂਜ—ਫਿਰ ਮੈਚ ਕਰ ਰਹੇ ਰਿਕਾਰਡਾਂ ਦੀ ਸਹੀ ਗਿਣਤੀ ਦਿਖਾਓ। ਇੱਕ ਛੋਟਾ ਨਮੂਨਾ (ਇੱਕ 10 ਆਈਟਮ) ਲੋਕਾਂ ਨੂੰ ਗਲਤ ਖੇਤਰ ਜਾਂ ਆਰਕੀਵ ਸਮੇਤ ਹੋਣ ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਨੋਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਇਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:

• ਇੱਕ ਡ੍ਰਾਈ-ਰਨ ਸਕ੍ਰੀਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਗਿਣਤੀ, ਫਿਲਟਰ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਰਿਕਾਰਡਾਂ ਦਾ ਛੋਟਾ ਨਮੂਨਾ ਦਿਖਾਏ
• ਇੱਕ ਸਪਸ਼ਟ ਸਕੋਪ ਚੋਣ ਲਾਜ਼ਮੀ ਕਰੋ (ਉਦਾਹਰਨ: “ਸਿਰਫ਼ Active ਗਾਹਕ Tenant A ਵਿੱਚ, 2024-01-01 ਤੋਂ ਪਹਿਲਾਂ ਬਣੇ”)
• ਹਰ ਰਨ ਲਈ ਹੀਪ (cap) ਲਗਾਓ (ਜਿਵੇਂ 1,000 ਰਿਕਾਰਡ) ਅਤੇ ਅਗਲੇ ਬੈਚ ਲਈ ਫਿਰ ਰਨ ਕਰਨ ਦੀ ਸੂਚਨਾ ਦਿਓ
• ਤਬਦੀਲੀਆਂ ਕੋਲ ਥਰੋਟਲ ਲਗਾਓ ਤਾਂ ਇੱਕ ਖਰਾਬ ਕਲਿੱਕ ਡੇਟਾਬੇਸ ਜਾਂ ਡਾਉਨਸਟ੍ਰੀਮ ਸਿਸਟਮ ਨੂੰ ਹਾਮਰ ਨਾ ਕਰ ਸਕੇ
• ਪ੍ਰਗਤੀ, ਲੌਗ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਰੱਦ ਕਰਨ ਦਾ ਵਿਕਲਪ ਦੇ ਕੇ ਕਿਊਡ ਜੌਬ ਵਜੋਂ ਚਲਾਓ

ਕਿਊਡ ਜੌਬ "ਫਾਇਰ-ਅੈਂਡ-ਫੋਰਗੇਟ" ਨਾਲੋਂ ਬੇਹਤਰ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕਾਗਜ਼ੀ ਨਿਸ਼ਾਨ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਜਦੋਂ ਓਪਰੇਟਰ 5% 'ਤੇ ਕੁਝ ਗਲਤ ਮਹਿਸੂਸ ਕਰੇ ਤਾਂ ਉਹ ਕਾਰਵਾਈ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ: ਇੱਕ ਓਪਰੇਟਰ ਧੋਖਾਧੜੀ ਦੇ ਉਤੱਪਰ ਲਗੇ ਹੋਣ ਤੇ ਉਪਭੋਗਤਾ ਖਾਤਿਆਂ ਨੂੰ ਬਲਕ ਰੂਪ ਵਿੱਚ ਅਯੋਗ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਪ੍ਰੀਵਿਊ 842 ਖਾਤਿਆਂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਨਮੂਨੇ ਵਿੱਚ VIP ਗਾਹਕ ਸ਼ਾਮਲ ਹਨ। ਇਹ ਛੋਟਾ ਨਿੜਾਨ ਅਕਸਰ ਇਸ ਗਲਤ ਫਿਲਟਰ ਨੂੰ ਰੋਕਦਾ ਹੈ: ਫਿਲਟਰ ਵਿੱਚ “fraud_flag = true” ਨਹੀਂ ਸੀ।

ਜੇ ਤੁਸੀਂ ਜਲਦੀ ਅੰਦਰੂਨੀ ਕੰਸੋਲ ਇਕੱਠਾ ਕਰ ਰਹੇ ਹੋ (ਅੱਗੇ Koder.ai ਵਰਗੇ build-by-chat ਪਲੇਟਫਾਰਮ ਨਾਲ), ਤਾਂ ਇਹ ਪੈਟਰਨ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਲਾਗੂ ਕਰੋ। ਇਹ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ ਜਿੰਨਾ ਕਿ ਉਹ ਜੋੜਦੇ ਹਨ।

ਐਸੀਆਂ ਪੁਸ਼ਟੀਆਂ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਪੁਸ਼ਟੀਆਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬਹੁਤ ਜਨਰਲ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਸਕ੍ਰੀਨ ਕਹਿੰਦੀ ਹੈ “ਕੀ ਤੁਸੀਂ ਯਕੀਨਨ ਹੋ?”, ਲੋਕ ਆਟੋਪਾਇਲਟ 'ਤੇ ਕਲਿੱਕ ਕਰ ਲੈਂਦੇ ਹਨ। ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪੁਸ਼ਟੀ ਉਹੀ ਭਾਸ਼ਾ ਵਰਤੀਦੀ ਹੈ ਜੋ ਤੁਹਾਡਾ ਯੂਜ਼ਰ ਆਪਣੀ ਟੀਮ ਨੂੰ ਨਤੀਜਾ ਸਮਝਾਉਣ ਲਈ ਵਰਤੇਗਾ।

ਪੁਰਾਣੇ, ਅਸਪਸ਼ਟ ਲੇਬਲਾਂ ਜਿਵੇਂ “Delete” ਜਾਂ “Apply” ਨੂੰ ਅਸਲ ਪ੍ਰਭਾਵ ਨਾਲ ਬਦਲੋ: “Deactivate 38 accounts”, “Remove access for this tenant”, ਜਾਂ “Void 12 invoices”。 ਇਹ ਸਭ ਤੋਂ ਸਧਾਰਨ ਸੁਧਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਡਾਟਾ ਨੁਕਸਾਨ ਰੋਕਣ ਵਾਲੇ ਐਡਮਿਨ টੂਲਾਂ ਲਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇਕ ਰਿਫਲੈਕਸ ਕਲਿੱਕ ਨੂੰ ਸਵੀਕਾਰਤਾ ਦੇ ਇਕ ਪਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਯੂਜ਼ਰ ਨੂੰ ਸਕੋਪ ਦੀ ਪੁਸ਼ਟੀ ਕਰਵਾਉ

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

ਉਦਾਹਰਨ: “Close accounts for Tenant: Acme Retail. Count: 38. Filter: last login before 2024-01-01.” ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮੁੱਲ ਗਲਤ ਲੱਗਦਾ ਹੈ, ਯੂਜ਼ਰ ਨੁਕਸਾਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਪਕੜ ਲਵੇਗਾ।

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

• ਇੱਕ ਛੋਟਾ ਵਾਕ ਜਾਂ ਫਰੇਜ਼ ਮੰਗੋ ਜਿਵੇਂ DELETE 38 ACCOUNTS
• ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਟੇਨੈਂਟ ਨਾਮ ਸੀਧਾ ਟਾਈਪ ਕਰਨ ਲਈ ਕਹੋ
• ਜਾਂ ਸਕ੍ਰੀਨ 'ਤੇ ਦਰਸ਼ਾਇਆ ਗਿਣਤੀ ਮੁੜ ਟਾਈਪ ਕਰਨ ਲਈ ਲੋੜ ਕਰੋ

ਸਿਰਫ਼ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਮਾਮਲਿਆਂ ਲਈ ਦੋ-ਕਦਮੀ ਬਣਾਓ

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

ਅੰਤ ਵਿੱਚ, “OK/Cancel” ਤੋਂ ਬਚੋ। ਬਟਨਾਂ ਤੇ ਸਪਸ਼ਟ ਲਿਖੋ ਕਿ ਕੀ ਹੋਵੇਗਾ: “Deactivate accounts” ਅਤੇ “Go back”。 ਇਸ ਨਾਲ ਗਲਤ ਕਲਿੱਕ ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਫੈਸਲਾ ਵਾਸਤਵ ਵਿੱਚ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਸੌਫਟ ਡਿਲੀਟ, ਰੀਸਟੋਰ ਅਤੇ ਰੀਟੇਨਸ਼ਨ ਨੀਤੀਆਂ

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

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

ਰੀਸਟੋਰ ਸਪਸ਼ਟ ਅਤੇ ਲੌਗ ਕੀਤੀ ਹੋਵੇ

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

ਰੀਟੇਨਸ਼ਨ ਨੀਤੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ ਇਹ ਸਵਾਲ ਜਵਾਬ ਕਰੋ:

• ਹਰ ਓਬਜੈਕਟ ਟਾਈਪ ਲਈ ਡਿਫ਼ੌਲਟ ਰੀਟੇਨਸ਼ਨ ਕੀ ਹੈ?
• ਕਿਹੜਾ ਰੋਲ ਰੀਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਉਹਨਾਂ ਨੂੰ ਕਾਰਨ ਦੱਸਣਾ ਲਾਜ਼ਮੀ ਹੈ?
• ਰੀਟੇਨਸ਼ਨ ਮਿਆਦ ਮੁੱਕਣ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ?
• ਕੌਣ ਨੀਤੀ ਨੂੰ ਕਾਨੂੰਨੀ ਜਾਂ ਬਿਲਿੰਗ ਮਾਮਲਿਆਂ ਲਈ ਵਧਾ ਸਕਦਾ ਹੈ?
• “ਮੇਰਾ ਡਾਟਾ ਮਿਟਾਓ” ਅਨੁਰੋਧਾਂ ਨੂੰ ਤੁਸੀਂ ਕਿਵੇਂ ਹੈਂਡਲ ਕਰੋਗੇ?

ਰੀਸਟੋਰ ਟੁੱਟਣ ਵਾਲੇ ਐਜ ਕੇਸ

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

ਹਾਰਡ ਡਿਲੀਟ ਕਮ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ uitzondering ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਓ, ਛੋਟੀ ਮਨਜ਼ੂਰੀ ਰਾਹੀ ਨਾਲ:

• ਸੌਫਟ ਡਿਲੀਟ ਨਾਲੋਂ ਉੱਚ ਰੋਲ ਦੀ ਲੋੜ ਰੱਖੋ
• ਟਾਈਪ ਕੀਤੀ ਪੁਸ਼ਟੀ ਅਤੇ ਕਾਰਨ ਮੰਗੋ
• ਡਿਲੀਟ ਨੂੰ ਕਿਊ ਕਰਕੇ ਦੇਰੇ ਨਾਲ ਚਲਾਓ (ਉਦਾਹਰਨ ਲਈ 24 ਘੰਟੇ)
• ਮਾਲਿਕ ਜਾਂ ਆਨ-ਕਾਲ ਚੈਨਲ ਨੂੰ ਸੂਚਿਤ ਕਰੋ
• ਹਟਾਏ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ ਅੰਤਮ ਆਡੀਟ ਰਿਕਾਰਡ ਰੱਖੋ

ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਐਡਮਿਨ ਨੂੰ Koder.ai 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਸੌਫਟ ਡਿਲੀਟ, ਰੀਸਟੋਰ ਅਤੇ ਰੀਟੇਨਸ਼ਨ ਨੂੰ ਪਹਿਲਾ-ਸ਼੍ਰੇਣੀ ਕਾਰਵਾਈਆਂ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਤਾਂ ਜੋ ਹਰ ਜਨਰੇਟ ਕੀਤੀ ਸਕ੍ਰੀਨ ਅਤੇ ਵਰਕਫਲੋ ਨੇ ਇਹ ਇਕਸਾਰ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਣ।

ਆਡੀਟੇਬਿਲਟੀ: ਕਾਰਵਾਈਆਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸਮਝਾਇਆ ਜਾ ਸਕੇ

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

ਸ਼ੁਰੂਆਤ ਇਸ ਤਰ੍ਹਾਂ ਕਰੋ ਕਿ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਨਸਾਨ-ਪੜ੍ਹਨਯੋਗ ਤਰੀਕੇ ਨਾਲ ਲੌਗ ਕਰੋ। “User 183 updated record 992” ਕੱਫੀ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਇਕ ਗ੍ਰਾਹਕ ਨਾਰਾਜ਼ ਹੈ ਅਤੇ on-call ਵਿਅਕਤੀ ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਵਧੀਆ ਲੌਗਾਂ ਵਿੱਚ ਪਛਾਣ, ਸਮਾਂ, ਸਕੋਪ, ਅਤੇ ਮਨੋਰਥ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾਲ ਹੀ ਰੋਲਬੈਕ ਕਰਨ ਲਈ ਕਾਫੀ ਵੇਰਵਾ।

ਕੀ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ (ਤਾਕਿ ਬਾਅਦ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੋਵੇ)

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ:

• ਕਿਸਨੇ ਕੀਤਾ (ਯੂਜ਼ਰ, ਰੋਲ, ਅਤੇ ਇੰਪర్సੋਨੇਸ਼ਨ ਜਾਣਕਾਰੀ ਜੇ ਵਰਤੀ ਗਈ)
• ਕੀ ਅਤੇ ਕਿੱਥੇ (ਕਾਰਵਾਈ ਦਾ ਨਾਮ, ਟੇਨੈਂਟ/ਖਾਤਾ, ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਆਬਜੈਕਟ ਕਿਸਮ)
• ਕਦ ਅਤੇ ਕਿੱਥੋਂ (ਟਾਈਮਸਟੈਂਪ, ਟਾਈਮਜ਼ੋਨ, IP ਜਾਂ ਡਿਵਾਈਸ/ਸੈਸ਼ਨ ID)
• ਕੀ ਬਦਲਿਆ (ਮੁੱਖ ਫੀਲਡਾਂ ਲਈ ਬੀਫੋਰ/ਆਫਟਰ, ਜਾਂ ਵੱਡੇ ਆਬਜੈਕਟਾਂ ਲਈ ਡਿਫ)
• ਕਿਉਂ ਹੋਇਆ (ਫ੍ਰੀ-ਟੈਕਸਟ ਕਾਰਨ ਅਤੇ ਇੱਕ ਵਿਕਲਪਿਕ ਟਿਕਟ/ਰੇਫਰੈਂਸ ID)

ਬਲਕ ਐਕਸ਼ਨਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਇਲਾਜ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਇਕੱਲੇ “ਜੌਬ” ਵਜੋਂ ਲੌਗ ਕਰੋ ਜਿਸ ਵਿੱਚ ਸਪਸ਼ਟ ਸਾਰ (ਕਿੰਨੇ ਚੁਣੇ, ਕਿੰਨੇ ਸਫ਼ਲ, ਕਿੰਨੇ ਫੇਲ) ਹੋਵੇ, ਅਤੇ ਹਰ ਆਈਟਮ ਦੇ ਨਤੀਜੇ ਵੀ ਸੰਭਾਲੋ। ਇਸ ਨਾਲ ਇਹ ਪਤਾ ਲਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ, “ਅਸੀਂ 200 ਆਰਡਰ ਰਿਫੰਡ ਕੀਤੇ ਜਾਂ ਸਿਰਫ਼ 173?” ਬਿਨਾਂ ਬੜੀ ਖੋਜ ਦੇ।

ਲੌਗਾਂ ਨੂੰ ਖੋਜਣਯੋਗ ਬਣਾਓ: ਐਡਮਿਨ ਯੂਜ਼ਰ, ਟੇਨੈਂਟ, ਕਾਰਵਾਈ ਦੀ ਕਿਸਮ ਅਤੇ ਸਮੇਂ ਦੀ ਰੇਂਜ ਨਾਲ ਫਿਲਟਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੋਵੇ। “ਬਲਕ ਜੌਬਜ਼ μόνο” ਅਤੇ “ਹਾਈ-ਰਿਸਕ ਕਾਰਵਾਈਆਂ” ਲਈ ਫਿਲਟਰ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆਕਾਰ ਰੁਝਾਨ ਵੇਖ ਸਕਣ।

ਬਿਊਰੋਕ੍ਰਸੀ ਨੂੰ ਲਾਜ਼ਮੀ ਨਾ ਬਣਾਓ। ਇੱਕ ਛੋਟਾ “ਕਾਰਨ” ਫੀਲਡ ਜੋ ਟੈਮਪਲੇਟਾਂ ("Customer requested closure", "Fraud investigation") ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ, ਲੰਮੇ ਫਾਰਮ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਵਧੇਰੇ ਭਰਿਆ ਜਾਵੇਗਾ। ਜੇ ਕੋਈ ਸਪੋਰਟ ਟਿਕਟ ਹੈ, ਲੋਕ ਉਸਦੀ ID ਪੇਸਟ ਕਰ ਸਕਦੇ ਹਨ।

ਅੰਤ ਵਿੱਚ, ਪੜ੍ਹਨ ਦੀ ਪਹੁੰਚ ਯੋਜਨਾ ਬਣਾਓ। ਬਹੁਤ ਸਾਰੇ ਅੰਦਰੂਨੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲੌਗ ਵੇਖਣ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਕੇਵਲ ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡ (ਪੂਰੇ ਬੀਫੋਰ/ਆਫਟਰ ਮੁੱਲ) ਵੇਖਣ ਦੀ ਆਗਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। “ਆਡੀਟ ਸੰਖੇਪ ਵੇਖ ਸਕਦਾ ਹੈ” ਅਤੇ “ਡੇਟੇਲ ਵੇਖ ਸਕਦਾ ਹੈ” ਨੂੰ ਵੱਖ-ਵੱਖ ਮਨਜ਼ੂਰੀਆਂ ਦਿਓ ਤਾਂ ਪ੍ਰਵੇਸ਼ ਘਟੇ।

ਰੋਲ-ਆਧਾਰਿਤ ਸੀਮਾਵਾਂ ਅਤੇ ਗਾਰਡਰੇਲ

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

ਰੋਲਾਂ ਨੂੰ ਅਸਲ ਕੰਮਾਂ ਅਨੁਸਾਰ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਟਾਈਟਲਾਂ ਅਨੁਸਾਰ ਨਹੀਂ। ਇੱਕ ਸਪੋਰਟ ਏਜੰਟ ਜਿਸਨੇ ਟਿਕਟਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੈ, ਉਸਨੂੰ ਬਿਲਿੰਗ ਨਿਯਮ ਮੈਨੇਜ ਕਰਨ ਵਰਗੇ ਐਕਸੈਸ ਦੀ ਲੋੜ ਨਹੀਂ।

ਕੰਮਾਂ ਅਨੁਸਾਰ ਰੋਲ ਬਣਾਓ

ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਚੀਜ਼ ਅਤੇ ਬਦਲਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਵੱਖ ਕਰੋ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸੈੱਟ ਰੋਲਾਂ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦੇ ਹਨ:

• Read-only: ਯੂਜ਼ਰ, ਆਰਡਰ ਅਤੇ ਲੌਗਾਂ ਵੇਖਣ
• Operator: ਪ੍ਰੋਫਾਈਲ ਸੋਧਣਾ ਅਤੇ ਪਾਸਵਰਡ ਰੀਸੈਟ
• Billing operator: ਇੱਕ ਕੈਪ ਤੱਕ ਰਿਫੰਡ ਜਾਰੀ ਕਰਨਾ
• Data steward: ਰਿਕਾਰਡ ਮਰਜ ਅਤੇ ਬਲਕ ਫਿਕਸ ਚਲਾਉਣਾ
• Security admin: ਖਾਤੇ ਅਯੋਗ ਕਰਨਾ ਅਤੇ ਰੋਲ ਮੈਨੇਜ ਕਰਨਾ

ਇਸ ਨਾਲ "ਡਿਲੀਟ" ਰੋਜ਼ਾਨਾ ਕੰਮ ਤੋਂ ਬਾਹਰ ਰਹੇਗਾ ਅਤੇ ਜਦੋਂ ਕੋਈ ਗਲਤੀ ਕਰੇਗੀ ਤਾਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘੱਟ ਹੋਵੇਗਾ।

ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਲਈ, ਇੱਕ elevated mode ਸ਼ਾਮਲ ਕਰੋ। ਇਸਨੂੰ ਸਮੇਂ-ਸੀਮਿਤ ਕੀ ਵਾਂਗ ਸਮਝੋ। elevated mode ਵਿੱਚ ਜਾਣ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਕਦਮ (ਰੀ-ਅਥੈਂਟ, ਮੈਨੇਜਰ ਮਨਜ਼ੂਰੀ, ਜਾਂ ਦੂਜੇ ਵਿਅਕਤੀ ਦੀ ਲੋੜ) ਲੋੜੀਂਦਾ ਹੋਵੇ ਅਤੇ ਇਹ 10-30 ਮਿੰਟਾਂ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਵੇ।

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

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

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਗਾਰਡਰੇਲ ਉਤਪਾਦ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਂਗ ਸਮਝੋ, ਬਾਅਦ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਵਾਂਗ ਨਹੀਂ। ਡਾਟਾ ਨੁਕਸਾਨ ਰੋਕਣ ਵਾਲੇ ਐਡਮਿਨ ਟੂਲ ਅਕਸਰ ਸਿਰਫ਼ ਚੰਗੀ ਪਰਮੀਸ਼ਨ ਡਿਜ਼ਾਈਨ ਅਤੇ ਕੁਝ ਵਧੀਆ ਸਪੀਡਬੰਦੀ ਹਨ।

ਇੱਕ ਹਕੀਕਤੀ ਸੈਨਾਰੀਓ: ਬਲਕ ਰਿਫੰਡਸ ਅਤੇ ਖਾਤਾ ਬੰਦ ਕਰਨਾ

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

ਖਤਰਾ ਇੱਕ ਛੋਟੀ ਡੀਟੇਲ ਵਿੱਚ ਆਉਂਦਾ ਹੈ: ਫਿਲਟਰ। ਏਜੰਟ "Orders created last 24 hours" ਚੁਣ ਲੈਂਦਾ ਹੈ ਬਜਾਏ "Orders paid during outage window." ਇੱਕ ਰੁੱਤ ਵਾਲੇ ਦਿਨ 'ਤੇ, ਇਹ ਸਹਜ਼ੀ ਤੌਰ 'ਤੇ ਹਜ਼ਾਰਾਂ ਆਮ ਗਾਹਕਾਂ ਨੂੰ ਖਿੱਚ ਸਕਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੇ ਰਿਫੰਡ ਦੀ ਮੰਗ ਨਹੀਂ ਕੀਤੀ। ਜੇ ਅਗਲਾ ਕਦਮ "ਰਿਫੰਡ ਕੀਤੀਆਂ ਆਰਡਰਾਂ ਲਈ ਖਾਤੇ ਬੰਦ ਕਰੋ" ਹੋਵੇ, ਤਬ ਨੁਕਸਾਨ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲ ਸਕਦਾ ਹੈ।

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

• ਕੁੱਲ ਖਾਤੇ ਜੋ ਬੰਦ ਹੋਣਗੇ (ਅਤੇ ਕਿੰਨੇ ਪਹਿਲਾਂ ਹੀ ਬੰਦ ਹਨ)
• ਕੁੱਲ ਰਿਫੰਡ ਰਕਮ, ਹਿੱਸੇ-ਨੂੰ-ਨੂੰ ਘੱਟੋ-ਘੱਟ/ਵੱਧ ਤੋਂ ਵੱਧ ਰਕਮ
• ਪ੍ਰਭਾਵਿਤ ਗਾਹਕਾਂ ਦਾ ਇੱਕ ਛੋਟਾ, ਸਕ੍ਰੋਲਯੋਗ ਨਮੂਨਾ (ਨਾਂ, ਈਮੇਲ, ਆਰਡਰ ID)
• ਬਹਿਸ-ਯੋਗਤਾ ਅਤੇ ਸਕਿਪਸ (ਫੇਲਡ ਭੁਗਤਾਨ, ਪਹਿਲਾਂ ਹੀ ਰਿਫੰਡ, ਵਿਵਾਦੀ ਆਰਡਰ)
• ਸਹੀ ਫਿਲਟਰ ਸਾਰ ਸੰਸਾਰੀ ਭਾਸ਼ਾ ਵਿੱਚ, ਸਾਫ਼ "Edit filter" ਬਟਨ ਨਾਲ

ਫਿਰ ਇੱਕ ਵੱਖਰੀ, ਦੂਜੀ ਪੁਸ਼ਟੀ ਜੋ ਖਾਤਾ ਬੰਦ ਕਰਨ ਲਈ ਹੋਵੇ, ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਵੱਖਰਾ ਤਰਾਂ ਦਾ ਨੁਕਸਾਨ ਹੈ। ਇੱਕ ਚੰਗਾ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਇੱਕ ਛੋਟਾ ਫਰੇਜ਼ ਟਾਈਪ ਕਰਵਾਓ ਜਿਵੇਂ "CLOSE 127 ACCOUNTS" ਤਾਂ ਕਿ ਏਜੰਟ ਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿ ਗਿਣਤੀ ਗਲਤ ਹੈ।

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

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

ਜੇ ਤੁਸੀਂ ਇਸ ਤਰਾਂ ਦੀ ਕਨਸੋਲ Koder.ai 'ਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ snapshots ਅਤੇ rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਧੀਆ ਗਾਰਡਰੇਲ ਹਨ, ਪਰ ਪਹਿਲੀ ਲੜੀ ਦੀ ਰੱਖਿਆ ਹਮੇਸ਼ਾ ਪ੍ਰੀਵਿਊ, ਪੁਸ਼ਟੀਆਂ ਅਤੇ ਰੋਲਾਂ ਹੀ ਹੈ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਮੌਜੂਦਾ ਐਡਮਿਨ ਵਿੱਚ ਸੁਰੱਖਿਆ ਜੋੜੋ

ਰੈਟ੍ਰੋਫਿਟ ਸੁਰੱਖਿਆ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਐਡਮਿਨ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਜੋਂ व्यवहार ਕਰੋ, ਨਾ ਕਿ ਅੰਦਰੂਨੀ ਪੰਨਿਆਂ ਦੇ ਢੇਰ ਵਜੋਂ। ਪਹਿਲਾਂ ਇਕ ਉੱਚ-ਖਤਰੇ ਵਾਰਕਫਲੋ (ਜਿਵੇਂ ਬਲਕ ਯੂਜ਼ਰ ਅਯੋਗ) ਚੁਣੋ, ਫਿਰ ਕਦਮ-ਬ-ਕਦਮ ਅੱਗੇ ਵਧੋ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰੈਟ੍ਰੋਫਿਟ ਯੋਜਨਾ

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

ਫਿਰ ਬਲਕ ਐਕਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਓ: ਸਕੋਪ ਅਤੇ ਪ੍ਰੀਵਿਊ ਮਜ਼ਬੂਰ ਕਰੋ। ਦਿਖਾਓ ਕਿ ਕਿਹੜੇ ਰਿਕਾਰਡ ਫਿਲਟਰਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਕਿੰਨੇ ਬਦਲਣਗੇ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਨਮੂਨਾ ID ਦੇਖਣ ਦਿਓ ਪਹਿਲਾਂ।

ਅਗਲਾ ਕਦਮ: ਹਾਰਡ ਡਿਲੀਟ ਵਜੋਂ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਸੌਫਟ ਡਿਲੀਟ ਲਿਆਓ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ। ਇੱਕ ਡਿਲੀਟ ਫਲੈਗ, ਕਿਸਨੇ ਕੀਤਾ, ਅਤੇ ਕਦੋਂ ਕੀਤਾ, ਸੰਭਾਲੋ। ਇੱਕ ਰੀਸਟੋਰ ਰਾਹ ਜੋ ਡਿਲੀਟ ਜਿਤਨਾ ਹੀ ਆਸਾਨ ਹੋਵੇ, ਜੋੜੋ, ਨਾਲ ਹੀ ਸਪਸ਼ਟ ਰੀਟੇਨਸ਼ਨ ਨੀਤੀਆਂ (ਉਦਾਹਰਨ ਲਈ, "30 ਦਿਨਾਂ ਲਈ ਰੀਸਟੋਰਯੋਗ")।

ਉਸ ਤੋਂ ਬਾਅਦ, ਆਡੀਟ ਲੌਗ ਜੋੜੋ ਅਤੇ ਓਪਰੇਟਰਾਂ ਦੇ ਨਾਲ ਬੈਠ ਕੇ ਅਸਲੀ ਲਾਇਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਜੇ ਕੋਈ ਲੌਗ ਲਾਈਨ "ਕਿਹੜਾ ਬਦਲਿਆ, ਕਿੱਥੋਂ ਕਿੱਥੇ, ਅਤੇ ਕਿਉਂ" ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਤਾਂ ਇਹ ਘਟਨਾ ਦੌਰਾਨ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ।

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

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ

ਇੱਕ ਓਪਰੇਟਰ ਨੂੰ 200 inactive ਖਾਤੇ ਬੰਦ ਕਰਨੇ ਹਨ। ਪਹਿਲਾਂ ਉਹ "Delete" ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਸੀ ਅਤੇ ਫਿਲਟਰ ਸਹੀ ਹੋਣ ਦੀ ਆਸ ਰੱਖਦਾ ਸੀ। ਰੈਟ੍ਰੋਫਿਟ ਤੋਂ ਬਾਅਦ, ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਵੈਰੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ("status=inactive, last_login>365d"), ਗਿਣਤੀ ਅਤੇ ਨਮੂਨਾ ਲਿਸਟ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, "Close (restorable)" ਚੁਣਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ delete, ਅਤੇ ਕਾਰਨ ਦਰਜ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਚੰਗਾ "ਮੁਕੰਮਲ" ਮਿਆਰ ਇਹ ਹੈ:

• ਤੁਸੀਂ ਪ੍ਰਭਾਵਿਤ ਸੈੱਟ ਨੂੰ ਪ੍ਰੀਵਿਊ ਅਤੇ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ ਪਹਿਲਾਂ ਚਲਾਉਣ ਤੋਂ।
• ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਿਤ ਵਿੰਡੋ ਵਿੱਚ ਅਣਡੂ (ਰੀਸਟੋਰ ਜਾਂ ਰੋਲਬੈਕ) ਕਰ ਸਕਦੇ ਹੋ।
• ਹਰ ਕਾਰਵਾਈ ਕਿਸੇ ਵਿਅਕਤੀ ਅਤੇ ਕਾਰਨ ਨਾਲ ਜੋੜੀ ਹੋਈ ਹੈ।
• ਉੱਚ-ਪ੍ਰਭਾਵ ਕਾਰਵਾਈਆਂ ਰੋਲ ਨਾਲ ਸੀਮਿਤ ਹਨ ਜਾਂ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਰੱਖਦੀਆਂ ਹਨ।

ਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਟੂਲ chat-driven ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai 'ਚ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਗਾਰਡਰੇਲ reusable components ਵਜੋਂ ਜੋੜੋ ਤਾ ਕਿ ਨਵੀਆਂ ਐਡਮਿਨ ਪੰਨੀਆਂ ਸੁਰੱਖਿਅਤ ਡਿਫ਼ੌਲਟ ਵਿਰਾਸਤ ਵਜੋਂ ਲਿਆਂਦੀਆਂ ਜਾਣ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਅਜੇ ਵੀ ਹਾਦਸੇ ਲੈਕੇ ਆਉਂਦੀਆਂ ਹਨ

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

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

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

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

ਇੱਥੇ ਉਹ ਗਲਤੀਆਂ ਹਨ ਜੋ ਵਾਰ-ਵਾਰ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ:

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

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਇੱਕ ਓਪਰੇਟਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ 12 ਖਾਤੇ sandbox ਟੇਨੈਂਟ ਵਿੱਚ ਅਯੋਗ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਪਰ ਟੂਲ ਆਖ਼ਰੀ ਵਰਤੇ ਗਏ ਟੇਨੈਂਟ ਨੂੰ ਡਿਫ਼ੌਲਟ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਸਿਰਫ਼ ਹੈਡਰ ਵਿੱਚ ਛੁਪਾ ਹੋਇਆ ਹੈ। ਉਹ ਬਲਕ ਐਕਸ਼ਨ ਚਲਾਉਂਦਾ ਹੈ, ਇਹ ਤੁਰੰਤ ਚੱਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਕੱਲਾ "ਲੌਗ" ਇੱਕ ਅਸਪਸ਼ਟ ਐਂਟਰੀ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ "bulk update completed." ਜਦ ਤੱਕ ਕਿਸੇ ਨੂੰ ਪਤਾ ਲੱਗੇ, ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਕਿ ਕੀ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਰੀਸਟੋਰ ਕਰਨਾ ਹੈ।

ਚੰਗੀ ਸੁਰੱਖਿਆ ਵਧੇਰੇ ਪੌਪਅਪ ਨਹੀਂ ਹੈ। ਇਹ ਹੈ ਸਪਸ਼ਟ ਸੰਦਰਭ, ਅਰਥਪੂਰਨ ਪੁਸ਼ਟੀਆਂ, ਅਤੇ ਐਸੇ ਕਾਰਜ ਜੋ ਤੁਸੀ ਟ੍ਰੈਕ ਅਤੇ ਰਿਵਰਸ ਕਰ ਸਕਦੇ ਹੋ।

ਛੇਤੀ ਚੈਕਲਿਸਟ ਅਤੇ ਅੱਗੇ ਦੇ ਕਦਮ

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

ਇੱਥੇ ਇੱਕ ਛੇਤੀ ਪ੍ਰੀ-ਫਲਾਈਟ ਚੈਕਲਿਸਟ ਹੈ ਜੋ ਡਾਟਾ ਨੁਕਸਾਨ ਰੋਕਣ ਵਾਲੇ ਐਡਮਿਨ ਟੂਲਾਂ ਲਈ ਹੈ:

• Scope + preview: ਉਹਨਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦਿਖਾਓ ਕਿ ਕੀ ਬਦਲੇਗਾ (ਕੌਣ, ਕੀ, ਕਿੱਥੇ)। ਪਾਠਯੋਗ ਪ੍ਰੀਵਿਊ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਰਿਕਾਰਡਾਂ ਦਾ ਨਮੂਨਾ ਸ਼ਾਮਲ ਕਰੋ।
• Counts + limits: ਆਈਟਮਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਦਿਖਾਓ ਅਤੇ ਸਮਝਦਾਰ caps (ਅਤੇ ਰੇਟ ਲਿਮਿਟ) ਲਾਗੂ ਕਰੋ ਤਾਂ ਕਿ ਇੱਕ ਕਲਿੱਕ "ਸਭ" ਨੂੰ ਛੂੰਹ ਨਾ ਸਕੇ।
• Context checks: ਓਪਰੇਟਰ ਨੂੰ ਟੇਨੈਂਟ/ਖਾਤਾ, ਵਾਤਾਵਰਣ (prod vs test) ਦੀ ਪੁਸ਼ਟੀ ਕਰਵਾਓ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਕਾਰਨ ਲਵੋ ਜੋ ਲੌਗ ਵਿੱਚ ਆਵੇ।
• Recovery path: ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਸੌਫਟ ਡਿਲੀਟ ਤਰਜੀਹ ਦਿਓ, ਰੀਸਟੋਰ ਫਲੋ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਰੀਟੇਨਸ਼ਨ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ (ਕਿੰਨੀ ਦੇਰ recovery ਸੰਭਵ ਹੈ)।
• Accountability: ਕਿਸਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ, ਕਿੱਥੇ, ਅਤੇ ਕਿਹੜੇ ਫਿਲਟਰ ਨਾਲ ਲਾਗ ਕਰਕੇ ਰਿੱਟੋਂ। ਲੌਗਾਂ ਨੂੰ ਖੋਜਯੋਗ ਬਣਾਓ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਰੋਲ ਅਸਲ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਓਪਰੇਟਰ ਹੋ, ਦੱਸੋ ਆਪਣੇ ਆਪ ਨੂੰ ਦਸ ਸਕਿੰਟ ਰੋਕਕੇ ਇਹ: “ਮੈਂ ਟੇਨੈਂਟ X 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ, N ਰਿਕਾਰਡ ਬਦਲ ਰਹਾ/ਰਹੀ ਹਾਂ, production ਵਿੱਚ, ਕਾਰਨ Y।” ਜੇ ਕੋਈ ਹਿੱਸਾ ਅਸਪਸ਼ਟ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਰੁਕੋ ਅਤੇ ਸੁਰੱਖਿਅਤ UI ਦੀ ਮੰਗ ਕਰੋ।

ਅਗਲਾ ਕਦਮ: Planning Mode ਵਿੱਚ Koder.ai 'ਤੇ ਜਲਦੀ ਸੁਰੱਖਿਅਤ ਫਲੋਜ਼ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ। ਟੈਸਟਿੰਗ ਦੌਰਾਨ snapshots ਅਤੇ rollback ਵਰਤੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਐਜ ਕੇਸ ਅਜ਼ਮਾ ਸਕੋ ਬਿਨਾਂ ਡਰ ਦੇ। ਜਦੋਂ ਫਲੋ ਠੀਕ ਲੱਗੇ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ ਤਿਆਰ ਹੋਣ 'ਤੇ ਡਿਪਲੋਯ ਕਰੋ।