10 ਦਸੰ 2025·8 ਮਿੰਟ
ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਡਿਜ਼ਾਈਨ ਜੋ 3 ਤੋਂ 30 ਐਪਸ ਤੱਕ ਸਕੇਲ ਕਰੇ
ਇੱਕ ਸਧਾਰਨ ਡੇਟਾ ਮਾਡਲ, ਸਪਸ਼ਟ ਸਥਿਤੀਆਂ, ਪਰਮਿਸ਼ਨ ਅਤੇ ਸੈਟਅਪ ਪ੍ਰਗਤੀ UI ਨਾਲ 3 ਤੋਂ 30 ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਤੱਕ ਸਕੇਲ ਕਰਨ ਲਈ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਡੇਟਾ ਮਾਡਲ, ਸਪਸ਼ਟ ਸਥਿਤੀਆਂ, ਪਰਮਿਸ਼ਨ ਅਤੇ ਸੈਟਅਪ ਪ੍ਰਗਤੀ UI ਨਾਲ 3 ਤੋਂ 30 ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਤੱਕ ਸਕੇਲ ਕਰਨ ਲਈ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਲੋਕ ਇੱਕ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਖੋਲ੍ਹਦੇ ਹਨ ਇੱਕ ਹੀ ਕਾਰਨ ਨਾਲ: ਟੂਲ ਜੋੜਨਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਚਲਦੇ ਰਹਿਣਾ। ਜੇ ਸਕ੍ਰੀਨ ਉਪਭੋਗੀ ਨੂੰ ਇਹ ਗੁੱਸਾ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਜੁੜਿਆ ਹੈ, ਕੀ ਖ਼ਰਾਬ ਹੈ, ਜਾਂ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ, ਤਾਂ ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘੱਟ ਹੁੰਦਾ ਹੈ।
3 ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਤੇ ਇੱਕ ਸਧਾਰਨ ਲੋਗੋ ਗ੍ਰਿਡ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। 30 ਤੇ ਇਹ ਟੁੱਟ ਜਾਂਦਾ ਹੈ: ਲੋਕ ਸਕੈਨ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਸਪੋਰਟ ਟਿਕਟ ਵੱਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ “Connect” ਬਟਨ ਫਸਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਵੱਖ-ਵੱਖ ਸਥਿਤੀ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ।
ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕਾਰਡ (ਜਾਂ ਰੋ) ਨੂੰ ਇੱਕ ਨਜਰ ਵਿੱਚ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ:
ਜ਼ਿਆਦਾਤਰ ਗੁੰਝਲਦਾਰੀਆਂ ਐਜ ਕੇਸਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਅਸਲ ਟੀਮਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਹੁੰਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਕਿਸੇ ਨੇ Google ਨੂੰ ਨਿੱਜੀ ਖਾਤੇ ਨਾਲ ਜੋੜ ਲਿਆ ਬਜਾਏ ਕੰਪਨੀ ਖਾਤੇ ਦੇ। Stripe ਟੋਕਨ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬਿਲਿੰਗ ਸਿੰਕ ਹੋਣਾ ਰੁਕ ਜਾਂਦਾ ਹੈ। Slack ਵਰਕਸਪੇਸ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਪਰ ਲੋੜੀਂਦੇ ਚੈਨਲ ਸਕੋਪ ਨਹੀਂ ਦਿੱਤੇ ਗਏ, ਤਾਂ ਸੈਟਅਪ "ਆਧਾ ਹੋਇਆ" ਹੋ ਸਕਦਾ ਹੈ ਜਦ UI ਠੀਕ ਦਿਖਦਾ ਹੈ।
ਇੱਕ ਵਧੀਆ ਸਕ੍ਰੀਨ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਸਾਫ਼ ਕਰ ਦਿੰਦੀ ਹੈ। ਸਿਰਫ਼ "Connected" ਦਿਖਾਉਣ ਦੀ ਬਜਾਏ, ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਓ: "Connected (needs permission)" ਜਾਂ "Connected to: [email protected]," ਅਤੇ ਕਾਰਡ 'ਤੇ ਹੀ ਅਗਲਾ ਕਦਮ ਰੱਖੋ। ਇਸ ਨਾਲ ਲੋਕ ਅਟਕਣ ਤੋਂ ਬਚਦੇ ਨੇ ਅਤੇ ਸੂਚੀ ਵਧਣ 'ਤੇ ਵੀ ਸਮਝ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।
ਸਭ ਤੋਂ ਸਧਾਰਨ ਤਰੀਕਾ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦਾ ਇਹ ਹੈ ਕਿ ਵੱਖਰਾ ਕੀਤਾ ਜਾਵੇ:
ਇਸ ਨਾਲ 3 ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਵੀ readability ਰਹਿੰਦੀ ਹੈ ਅਤੇ 30 ਤੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ।
ਇੱਕ Integration ਕੈਟਾਲੋਗ ਐਨਟਰੀ ਹੈ। ਇਹ ਗਲੋਬਲ ਹੈ, ਕਿਸੇ ਵੀ ਵਰਕਸਪੇਸ ਨਾਲ ਨਹੀਂ ਜੁੜਿਆ।
ਇੱਕ Install ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੋਈ ਵਰਕਸਪੇਸ ਉਸ Integration ਨੂੰ ਐਨੇਬਲ ਕਰ ਚੁੱਕਾ ਹੈ (ਉਦਾਹਰਨ: “Slack Workspace A ਲਈ ਚਾਲੂ ਕੀਤਾ ਗਿਆ”)।
ਇੱਕ Connection ਅਸਲ ਬਾਹਰੀ ਅਕਾਊਂਟ ਜਾਂ ਕ੍ਰੈਡੈਂਸ਼ਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਨ: “Slack workspace X via OAuth” ਜਾਂ “Stripe account Y via API key”). ਇੱਕ Install ਦੇ ਹੇਠਾਂ ਕਈ Connections ਹੋ ਸਕਦੇ ਹਨ।
ਨਿਮਨਲਿਖਤ ਖੇਤਰੀਆਂ ਦੀ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਸੈਟ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀ ਸਕੇਲਿੰਗ ਦਿੰਦੀ ਹੈ:
ਉਪਭੋਗੀ-ਦਿੱਖ ਵਾਲੀ ਕਨਫਿਗ (ਚੁਣਿਆ ਹੋਇਆ ਚੈਨਲ, webhook URL nickname, enabled events) ਨੂੰ Install ਜਾਂ Connection 'ਤੇ ਸਧਾਰਨ ਡੇਟਾ ਵਜੋਂ ਰੱਖੋ। ਸੀਕ੍ਰੇਟ (OAuth refresh tokens, API keys, signing secrets) ਨੂੰ ਸਿਰਫ़ secrets store ਜਾਂ ENCRYPTED ਫੀਲਡ ਵਿੱਚ ਰੱਖੋ ਜਿਸ ਉੱਤੇ ਸਖਤ ਐਕਸੇਸ ਕੰਟਰੋਲ ਹੋਵੇ।
ਸੀਕ੍ਰੇਟ, ਪੂਰੇ authorization ਕੋਡ ਜਾਂ ਰਾ webhook payloads ਨੂੰ ਲਾਗਾਂ ਵਿੱਚ ਨਾ ਰੱਖੋ। ਜੇ ਕੁਝ ਲਾਗ ਕਰਨਾ ਜਰੂਰੀ ਹੈ ਤਾਂ ਰਿਫਰੈਂਸ (connection_id) ਅਤੇ ਸੁਰੱਖਿਅਤ ਮੈਟਾ-ਡੇਟਾ (HTTP status, error code) ਲਾਗ ਕਰੋ।
OAuth, API keys, ਅਤੇ webhooks ਵਿਚਲੀਆਂ ਵੱਖ-ਵੱਖ ਢਾਂਚਿਆਂ ਲਈ ਲਚਕੀਲਾਪਨ ਰੱਖਣ ਲਈ auth-ਖ਼ਾਸ ਫੀਲਡਸ ਨੂੰ Connection ਵਿਚ ਰੱਖੋ (token metadata vs key fingerprint vs webhook verification status)। UI-ਦੇਖਣ ਵਾਲੀ ਸਥਿਤੀ (enabled ਅਤੇ setup progress) ਨੂੰ Install 'ਤੇ ਰੱਖੋ।
ਉਪਭੋਗੀ ਡਾਇਰੈਕਟਰੀ ਖੋਲ੍ਹ ਕੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਤੁਰੰਤ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ: ਕੀ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਸੈਟਅਪ ਕਿੰਨਾ ਅੱਗੇ ਹੈ, ਅਤੇ ਮੈਨੂੰ ਅਗਲਾ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਸਥਿਤੀ ਦੇ ਸ਼ਬਦ ਧੁੰਦਲੇ ਹਨ, ਤਾਂ ਸਪੋਰਟ ਟਿਕਟ ਵੱਧਣਗੀਆਂ ਅਤੇ ਭਰੋਸਾ ਘਟੇਗਾ।
ਕੁਝ ਸਾਲਾਂ ਤੱਕ ਰੱਖ ਸਕਦੇ ਹੋਏ ਛੋਟੀ ਸਥਿਤੀ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਸੰਗ੍ਰਹਿਤ (stored) ਲੇਬਲਾਂ ਦੀ ਥਾਂ ਨਿਕਲ ਕੇ ਬਣਾਈਆਂ ਸਥਿਤੀਆਂ (derived status) ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਸੰਭਾਲੇ ਗਏ ਲੇਬਲ ਜ਼ਿਆਦਾ ਦੇਰ ਵਿੱਚ ਗਿਰ ਸਕਦੇ ਹਨ: ਕਿਸੇ ਨੇ ਏਰਰ ਠੀਕ ਕਰ ਦਿੱਤਾ ਪਰ ਬੈਜ ਲਾਲ ਰਿਹਾ। Derived status ਉਹ ਤੱਥਾਂ ਤੋਂ ਹਿਸਾਬ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਟ੍ਰੈਕ ਕਰਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਟੋਕਨ ਵੈਧ ਹਨ ਜਾਂ ਨਹੀਂ, ਲੋੜੀਂਦੇ ਸੈਟਅਪ ਸਟੈਪ ਪੂਰੇ ਹੋਏ ਹਨ, ਅਤੇ ਕੀ ਕਿਸੇ ਐਡਮਿਨ ਨੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਨੂੰ ਰੋਕਿਆ ਹੈ। ਜੇ ਕੁਝ ਸਟੋਰ ਕਰਨਾ ਹੈ ਤਾਂ ਅੰਤਿਮ ਲੇਬਲ ਨਾ, ਪਰ ਫੈਕਟਸ (last successful sync, last error code) ਸਟੋਰ ਕਰੋ।
ਸੈਟਅਪ ਪ੍ਰਗਤੀ ਇੱਕ ਛੋਟੇ ਚੈੱਕਲਿਸਟ ਵਜੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ, ਲੋੜੀਂਦੇ ਅਤੇ ਵਿਕਲਪਿਕ ਵਿੱਚ ਸਾਫ਼ ਵੰਡ ਨਾਲ। ਇਸਨੂੰ ਸਟੈਪ ਪਰਿਭਾਸ਼ਾਵਾਂ (ਸਤਤ, ਪ੍ਰਤੀ ਇੰਟਿਗ੍ਰੇਸ਼ਨ) ਅਤੇ ਸਟੈਪ ਨਤੀਜੇ (ਪ੍ਰਤੀ install) ਵਜੋਂ ਮਾਡਲ ਕਰੋ।
ਉਦਾਹਰਨ: Slack ਲਈ “Authorize workspace” ਅਤੇ “Select channels” ਲਾਜ਼ਮੀ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ “Enable message previews” ਇਕ ਵਿਕਲਪਿਕ। UI “2 of 3 required steps complete” ਦਿਖਾ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਵਿਕਲਪਿਕ ਆਈਟਮਾਂ ਨੂੰ ਖੋਜਯੋਗ ਰੱਖਿਆ ਜਾਵੇ।
ਇੱਕ ਇੰਸਟਾਲ ਹੇਠਾਂ ਕਈ ਕਨੈਕਸ਼ਨ ਹੋਣ ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਗੰਦੀ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਤੁਸੀਂ ਇਸ ਦੀ ਯੋਜਨਾ ਨਾ ਬਣਾਓ। ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਲਈ ਇੱਕ ਕਾਰਡ ਰੱਖੋ, ਕਨੈਕਸ਼ਨ ਗਿਣਤੀ ਦਿਖਾਓ, ਅਤੇ ਸਥਿਤੀ ਨੂੰ ਸੱਚਾਈ ਨਾਲ ਰੋਲ-ਅੱਪ ਕਰੋ। ਜੇ ਕੋਈ ਵੀ ਕਨੈਕਸ਼ਨ ਖਰਾਬ ਹੈ, “Needs attention” ਦਿਖਾਓ ਅਤੇ ਸੰਕੇਤ ਦੇਓ ਜਿਵੇਂ “1 of 4 workspaces needs re-auth.” ਅਵਲੋਕਨ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ ਪਰ ਹਾਲਤ ਦਾ ਸੱਚਾ ਦਰਸਨ ਵੀ ਰਹਿੰਦਾ ਹੈ।
ਜਦੋਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਸਵਿੱਚ ਵਜੋਂ ਟ੍ਰੀਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਪਰਮਿਸ਼ਨਾਂ ਘੁੰਮਣ ਵਾਲੀਆਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿ ਵੱਖਰਾ ਕਰੋ:
ਸਭ ਥਾਂ ਲਾਗੂ ਹੋਣ ਵਾਲਾ ਇੱਕ ਹਲਕਾ ਰੋਲ ਚੈੱਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਉਤਪਾਦਾਂ ਲਈ, ਤਿੰਨ ਰੋਲ ਕਾਫੀ ਹੁੰਦੇ ਹਨ: Admin, Manager, Member. Admins ਹਰ ਚੀਜ਼ ਕਰ ਸਕਦੇ ਹਨ। Managers ਆਪਣੀ ਟੀਮ ਲਈ ਬਹੁਤ ਸਾਰੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਸੈਟਅਪ ਕਰ ਸਕਦੇ ਹਨ। Members ਪਹਿਲੋਂ ਤੋਂ ਐਨੇਬਲ ਕੀਤੀਆਂ ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਵਰਤ ਸਕਦੇ ਹਨ, ਪਰ ਸੈਟਿੰਗ ਨਹੀਂ ਬਦਲ ਸਕਦੇ।
ਫਿਰ ਜਿੱਥੇ ਜਰੂਰਤ ਹੋਵੇ, ਪ੍ਰਤੀ-ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਪਰਮਿਸ਼ਨ ਫਲੈਗ ਜੁੜੋ। ਜ਼ਿਆਦਾਤਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ (ਕੈਲੰਡਰ, ਚੈਟ) ਡਿਫ਼ੌਲਟ ਰੋਲ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦੇ ਹਨ। ਸੰਵੇਦਨਸ਼ੀਲ ਇੱਕਾਂ (payments, payroll, exports) ਲਈ ਵਾਧੂ ਚੈੱਕ ਜਿਵੇਂ “Payments admin” ਜਾਂ “Billing manager” ਲਗਾਓ। ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਨ ਬੂਲੀਅਨ ਦੇ ਰੂਪ ਵਿੱਚ Install 'ਤੇ ਰੱਖੋ, ਨ ਕਿ ਨਵਾਂ ਰੋਲ-ਸਿਸਟਮ ਬਣਾਓ।
ਪੜਚੋਲ (audit) ਭਾਰੀ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੰਨਾਂ ਗੱਲਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ ਕਿ ਸਪੋਰਟ ਅਤੇ ਸੁਰੱਖਿਆ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦਿੱਤਾ ਜਾ ਸਕੇ: ਕਿਸਨੇ ਕਦੋਂ ਜੋੜਿਆ, ਕਦੋਂ ਕ੍ਰੈਡੈਂਸ਼ਲ ਬਦਲੇ, ਅਤੇ ਕਿਸਨੇ ਇੰਸਟਾਲ ਨੂੰ ਅਯੋਗ ਕੀਤਾ। ਡੀਟੇਲ ਪੇਜ 'ਤੇ 5-20 ਹਾਲੀਆ ਇਵੈਂਟਾਂ ਵਾਲਾ “Activity” ਪੈਨਲ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।
ਉਦਾਹਰਨ: Stripe ਹਰ ਕੋਈ ਵੇਖ ਸਕਦਾ ਹੈ, ਪਰ ਕੇਵਲ Admins (ਜਾਂ “Billing manager”) ਹੀ ਉਹਨੂੰ ਕਨੈਕਟ, ਕੀ ਰੋਟੇਟ, ਜਾਂ payouts ਬੰਦ ਕਰ ਸਕਦੇ ਹਨ। Slack Managers ਨੂੰ ਕਨੈਕਟ ਕਰਨ ਦਿੰਦਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਦਕਿ Members ਸੂਚਨਾਵਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਇਹ ਐਨੇਬਲ ਹੋ।
3 ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਦਿਖਾ ਸਕਦੇ ਹੋ। 30 'ਤੇ, ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਇੱਕ ਤੇਜ਼ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: "ਕਿਹੜੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਅਤੇ ਮੈਨੂੰ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ?" ਸਭ ਤੋਂ ਸਾਫ਼ ਤਰੀਕਾ ਸਕੈਨਿੰਗ ਨੂੰ ਅਲੱਗ ਕਰਕੇ ਕਰਨਾ ਅਤੇ ਕਰਨ ਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਅਲੱਗ ਰੱਖਣਾ ਹੈ।
ਡਾਇਰੈਕਟਰੀ ਦ੍ਰਿਸ਼ ਨੂੰ ਤੇਜ਼ ਫੈਸਲੇ ਲਈ ਕੇਂਦਰਿਤ ਰੱਖੋ। ਭਾਰੀ ਕੰਟਰੋਲ ਨੂੰ ਇੱਕ ਡੀਟੇਲ ਪੇਜ ਵਿੱਚ ਧੱਕੋ ਜੋ ਇਕ “Manage” ਬਟਨ ਦੇ ਪਿੱਛੇ ਖੁਲਦਾ ਹੈ।
ਲਿਸਟ ਵਿੱਚ ਸਿਰਫ ਉਹੀ ਦਿਖਾਓ ਜੋ ਅਗਲੇ ਕਲਿੱਕ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ:
ਕਾਰਡ ਦੀ ਬਣਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮਸ਼ੀਨ-ਮੇਮਰੀ ਬਣਾਉਂਦੀ ਹੈ। ਪ੍ਰਾਇਮਰੀ ਕਾਰਵਾਈ ਹਮੇਸ਼ਾ “ਅਗਲਾ ਕਦਮ” ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ: ਨਵੇਂ ਲਈ Connect, ਆਧੇ-ਪੂਰੇ ਲਈ Continue setup, auth ਮਿਆਦ ਖਤਮ ਹੋਣ 'ਤੇ Reconnect, ਅਤੇ ਸਭ ਠੀਕ ਹੋਣ 'ਤੇ Manage। ਹਰ ਕਾਰਡ 'ਤੇ ਦੋ ਸਮਾਨ ਤਾਕਤ ਵਾਲੇ ਬਟਨਾਂ ਤੋਂ ਬਚੋ — ਇਹ ਪੰਨਾ ਸ਼ੋਰਗੁਲ ਭਰਦਾ ਹੈ।
ਉਦਾਹਰਨ:
ਖਾਲੀ ਸਥਿਤੀਆਂ ਸਲਾਹ ਦੇਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਬਿਨਾਂ ਪੂਰਾ ਮੈਨੁਅਲ ਲਾ ਦਿੱਤੇ:
ਇਸ ਨਾਲ ਪੰਨਾ 30 ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ 'ਤੇ ਵੀ ਸ਼ਾਂਤ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕਾਰਡ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਹ ਕੀ ਹੈ, ਕੀ ਠੀਕ ਹੈ, ਅਤੇ ਹੁਣ ਕੀ ਕਰਨਾਂ।
ਡਾਇਰੈਕਟਰੀ ਲਿਸਟ ਲੋਕਾਂ ਨੂੰ ਸਹੀ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਡੀਟੇਲ ਪੇਜ ਓਥੇ ਹੈ ਜਿੱਥੇ ਉਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ: ਸੈਟਅਪ ਕਰਨਾ, ਠੀਕ ਕਰਨਾ, ਜਾਂ ਬੰਦ ਕਰਨਾ। ਪੇਜ ਦੀ ਬਣਤਰ ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ 'ਤੇ ਲਗਾਤਾਰ ਰੱਖੋ, ਭਾਵੇਂ ਬੈਕਐਂਡ ਵੱਖਰਾ ਹੋਵੇ।
ਸੰਖੇਪ ਓਵਰਵਿਊ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਨਾਮ, ਇੱਕ ਲਾਈਨ ਦੀ ਵਿਆਖਿਆ, ਅਤੇ ਸਪਸ਼ਟ ਸਥਿਤੀ ਲੇਬਲ (Connected, Needs attention, Disabled)। ਇੱਕ ਛੋਟਾ “Setup progress” ਲਾਈਨ ਜੋੜੋ ਤਾਂ ਉਪਭੋਗੀ ਜਾਣ ਸਕਣ ਕਿ ਉਹ ਇੱਕ ਕਦਮ ਤੋਂ ਪੂਰੇ ਹਨ ਜਾਂ ਸ਼ੁਰੂ 'ਤੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਵਿਜ਼ਾਰਡ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: 3-6 ਸਟੈਪ, ਇੱਕ ਸਮੇਂ ਇੱਕ ਸਕ੍ਰੀਨ, ਅਤੇ “Back” ਹਮੇਸ਼ਾ ਉਪਲਬਧ। ਸਟੈਪਾਂ ਦੇ ਨਾਮ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਰੱਖੋ (Connect account, Choose workspace, Pick data to sync, Confirm)। ਜੇ ਕਿਸੇ ਸਟੈਪ ਵਿੱਚ ਵਿਕਲਪਿਕ ਚੋਣਾਂ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਿਕਲਪਿਕ ਲੇਬਲ ਨਾਲ ਦਿਖਾਓ।
ਜੇ ਸੈਟਅਪ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਾਫ਼ ਕਹੋ: “You can finish later. We’ll keep your choices.” ਇਹ ਕਲਿਕ ਕਰ ਕੇ ਦੂਰ ਹੋਣ ਦਾ ਡਰ ਘਟਾਉਂਦਾ ਹੈ।
Connections ਨੂੰ ਇੱਕ ਛੋਟੀ ਟੇਬਲ ਵਜੋਂ ਦਿਖਾਓ: ਅਕਾਊਂਟ ਨਾਮ, ਜਿਸਨੇ ਜੋੜਿਆ (ਉਪਭੋਗੀ), ਬਣਾਉਣ ਦੀ ਤਾਰੀਖ, ਅਤੇ ਆਖਰੀ ਸਿੰਕ।
“ਅਗਲਾ ਸਿੰਕ” ਲਈ ਐਸੇ ਵਾਅਦੇ ਨਾ ਕਰੋ ਜੋ ਤੁਸੀਂ ਪੂਰੇ ਨਹੀਂ ਕਰ ਸਕਦੇ (ਜਿਵੇਂ ਨਿਰਧਾਰਿਤ ਸਮਾਂ)। ਉਹ ਸ਼ਬਦ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਸੰਭਾਲ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ “Next sync: scheduled soon” ਜਾਂ “Next sync: within the next hour,” ਜਿਸਦੇ ਅਧਾਰ ਤੇ ਤੁਹਾਡੀ ਸਿਸਟਮ ਹਕੀਕਤ ਵਿੱਚ ਖੜੀ ਰਹਿ ਸਕਦੀ ਹੈ।
ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਨੂੰ ਮੁੱਖ ਰਸਤੇ ਤੋਂ ਦੂਰ ਰੱਖੋ। ਪ੍ਰਾਇਮਰੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਉੱਤੇ ਰੱਖੋ (Continue setup, Reconnect)। Disable ਅਤੇ Disconnect ਨੂੰ ਇੱਕ ਅਲੱਗ “Danger zone” ਹਿੱਸੇ ਵਿੱਚ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਪ੍ਰਭਾਵ ਦਾ ਛੋਟਾ ਵੇਰਵਾ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਰੋਲਸ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਦੱਸੋ (ਉਦਾਹਰਨ: “Only admins can disconnect”).
ਇੱਕ ਛੋੱਟਾ activity log ਜੋੜੋ: ਹਾਲੀਆ ਇਵੈਂਟ (connected, token refreshed, sync failed), ਟਾਈਮਸਟੈਮਪ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਗਲਤੀ ਸੁਨੇਹਾ ਜੋ ਉਪਭੋਗੀ ਸਪੋਰਟ ਟਿਕਟ ਵਿੱਚ ਕਾਪੀ ਕਰ ਸਕੇ।
ਇੱਕ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਸ਼ਾਮਿਲ ਕਰਨਾ ਆਸਾਨ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਛੋਟੇ ਉਤਪਾਦ ਵਾਂਗ ਦੇਖਦੇ ਹੋ। ਇਸਨੂੰ ਇੱਕ ਲਿਸਟਿੰਗ, ਜੁੜਨ ਦਾ ਤਰੀਕਾ, ਇੱਕ ਕਨੈਕਸ਼ਨ ਸਟੋਰ ਕਰਨ ਦੀ ਥਾਂ, ਅਤੇ ਸਫਲਤਾ ਜਾਂ ਅਸਫਲਤਾ ਲਈ ਸਪਸ਼ਟ ਨਤੀਜੇ ਚਾਹੀਦੇ ਹਨ।
ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਨੂੰ ਆਪਣੇ ਕੈਟਾਲੋਗ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਦਿਖਾਈ ਦੇਵੇ ਭਾਵੇਂ ਕਿਸੇ ਨੇ ਹੁਣ ਤੱਕ ਜੋੜਿਆ ਨਾ ਹੋਵੇ। ਇੱਕ ਸਪਸ਼ਟ ਨਾਮ, ਛੋਟੀ ਵੇਰਵਾ, ਆਈਕਨ, ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ ਕੈਟੇਗਰੀਆਂ (Messaging, Payments) ਸ਼ਾਮਿਲ ਕਰੋ। ਸੈਟਅਪ ਉਮੀਦਾਂ ਸਾਫ਼ ਲਿਖੋ, ਜਿਵੇਂ “Connect an account” ਅਤੇ “Choose a workspace.” ਇਹ ਉਹ ਥਾਂ ਵੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਆਗੇ ਲੋੜਾਂ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋਗੇ (OAuth scopes, ਲੋੜੀਂਦੇ ਫੀਲਡ, ਸਮਰਥਿਤ ਫੀਚਰ)।
ਸਰਲ ਤਰੀਕਾ ਚੁਣੋ ਜੋ ਪ੍ਰੋਵਾਇਡਰ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ:
ਜਦ ਯੂਜ਼ਰ ਫਲੋ ਪੂਰਾ ਕਰ ਲੈਂਦਾ ਹੈ, ਇੱਕ Connection record ਬਣਾਓ ਜੋ ਉਸਦੇ ਵਰਕਸਪੇਸ ਜਾਂ ਅਕਾਊਂਟ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ, ਸਿਰਫ ਯੂਜ਼ਰ ਨਾਲ ਨਹੀਂ। ਕ੍ਰੈਡੈਂਸ਼ਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕਰੋ (rest ਤੀENCRYPTED ਅਤੇ ਪੂਰਾ ਸੀਕ੍ਰੇਟ ਮੁੜ ਨਹੀਂ ਦਿਖਾਉਣਾ)। ਸਪੋਰਟ ਲਈ ਉਹ ਬੁਨਿਆਦੀ ਜਾਣਕਾਰੀ ਸੇਵ ਕਰੋ: provider account ID, ਬਣਾਉਣ ਦਾ ਸਮਾਂ, ਜਿਸਨੇ ਜੋੜਿਆ, ਅਤੇ ਕੀ permissions ਦਿੱਤੇ ਗਏ।
ਤੁਰੰਤ ਹੀ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਚਲਾਓ (Stripe ਲਈ: account details ਲੋਡ ਕਰੋ)। ਜੇ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ Connected ਦਿਖਾਓ ਅਤੇ ਪ੍ਰਗਤੀ ਨੂੰ ਤਿਆਰ ਚਿੰਨ੍ਹਿਤ ਕਰੋ। ਜੇ ਅੱਧਾ ਪਾਸ ਹੁੰਦਾ ਹੈ (ਜੁੜਿਆ ਪਰ permissions ਘੱਟ), Needs attention ਦਿਓ ਅਤੇ ਸੀਧਾ ਅਗਲਾ ਫਿਕਸ ਦਿਖਾਓ।
ਇੱਕ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ, ਇੱਕ ਸੁਧਾਰ ਕਰਨਾ ਵਰਤਿਆ ਐਕਸ਼ਨ, ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ fallback। ਉਦਾਹਰਨ: “We couldn’t reach Stripe. Check the API key or try again.” ਇੱਕ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਖਰਾਬ ਹੋਣ 'ਤੇ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਅਜੇ ਵੀ ਵਰਤਣਯੋਗ ਰੱਖੋ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ Planning Mode ਵਿੱਚ ਕੈਟਾਲੋਗ, ਸੈਟਅਪ ਫਲੋ, ਅਤੇ ਸਥਿਤੀ ਨਿਯਮ ਡਰਾਫਟ ਕਰੋ, ਫਿਰ ਉਸ ਯੋਜਨਾ ਤੋਂ UI ਅਤੇ ਬੈਕਐਂਡ ਬਣਾਓ।
ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਾਸ਼ਜਨਕ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਡਾਇਰੈਕਟਰੀ ਉਹਨਾਂ ਕਾਰਨਾਂ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਸਮਝਾ ਸਕਦੀ, ਤਾਂ ਉਪਭੋਗੀ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਦੋਸ਼ ਦੇਂਦੇ ਹਨ ਅਤੇ ਸਪੋਰਟ ਕੋਲ ਕੰਮ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ।
ਫੇਲਿਊਰਜ਼ ਨੂੰ اُن ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ ਜੋ ਅਸਲ ਸੁਧਾਰਾਂ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ: login expired, missing permission, provider outage, ਜਾਂ rate limit। ਅੰਦਰੂਨੀ ਐਰਰ ਕੋਡ ਖ਼ੂਬ ਵੇਰਵਾ ਰੱਖੋ, ਪਰ ਉਪਭੋਗੀ ਨੂੰ ਇੱਕ ਛੋਟਾ ਸਮਝਣਯੋਗ ਲੇਬਲ ਦਿਖਾਓ।
ਜੇ ਕੁਝ ਟੁਟਦਾ ਹੈ, ਸੁਨੇਹਾ تین ਚੀਜ਼ਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਕੀ ਹੋਇਆ, ਉਪਭੋਗੀ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਸਿਸਟਮ ਅਗਲੇ ਕਦਮ ਵਜੋਂ ਕੀ ਕਰੇਗੀ। ਉਦਾਹਰਨ: “Slack connection expired. Reconnect to continue syncing. We’ll retry automatically once you reconnect.” ਇਹ ਇੱਕ ਕੱਚੇ API error ਦੇ ਮੁਕਾਬਲੇ ਜ਼ਿਆਦਾ ਸ਼ਾਂਤ ਅਤੇ ਕਾਰਵਾਈਯੋਗ ਹੈ।
ਆਟੋ-ਰਿਟ੍ਰਾਈ ਸਿਰਫ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਕਰੋ ਜਿੱਥੇ ਉਪਭੋਗੀ ਖੁਦ ਸੁਧਾਰ ਨਹੀਂ ਕਰ ਸਕਦਾ:
ਸਥਿਤੀਆਂ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਰਿਫਰੈਸ਼ ਨਾ ਕਰੋ। ਇੱਕ ਹਲਕਾ health check ਜੋਬ ਜੋ ਨਿਯਮਤ ਤੌਰ ਤੇ ਟੋਕਨ ਵਰਕ ਕਰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਆਖਰੀ ਸਿੰਕ ਚਲਿਆ ਕਿ ਨਹੀਂ, ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਬੈਜ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਚਲਾਉ।
ਹਰ install ਲਈ ਛੋਟਾ ਇਵੈਂਟ ਇਤਿਹਾਸ ਰੱਖੋ। ਤੁਹਾਨੂੰ ਪੂਰੇ ਲੋਗ ਦੀ ਲੋੜ ਨਹੀਂ, ਸਿਰਫ ਕਾਫੀ breadcrumbs: ਟਾਈਮਸਟੈਂਪ, ਇਵੈਂਟ (“token refreshed”, “sync failed”), ਛੋਟਾ ਕਾਰਨ, ਅਤੇ ਜਿਸਨੇ ਟ੍ਰਿੱਗਰ ਕੀਤਾ (ਉਪਭੋਗੀ ਜਾਂ ਸਿਸਟਮ)। ਸਪੋਰਟ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ-ਕੇਵਲ ਨੋਟਸ ਫੀਲਡ ਰੱਖੋ ਤਾਂ ਕਿ ਉਹ ਦੱਸ ਸਕਣ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਕਿੰਝ ਤਬਦੀਲੀ ਕੀਤੀ ਅਤੇ ਕਿਉਂ।
ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਐਪਸ ਤੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਧਦੇ ਹੋ, ਡਾਇਰੈਕਟਰੀ ਤੇਜ਼ੀ ਨਾਲ ਗੰਦੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਟੀਚਾ ਸਧਾਰਨ ਹੈ: ਲੋਕਾਂ ਨੂੰ ਜੋ ਉਨ੍ਹਾਂ ਚਾਹੀਦਾ ਹੈ ਸਕਿੰਨਾਂ ਵਿੱਚ ਮਿਲੇ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਮੱਸਿਆਵਾਂ ਛੇਤੀ ਮਿਲਣ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਅਤੇ ਕੈਟੇਗਰੀ 'ਤੇ ਸਧਾਰਨ ਖੋਜ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗੀ ਉਹੀ ਟਾਈਪ ਕਰਦੇ ਹਨ ਜੋ ਉਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਨ ("Slack", "Stripe"), ਇਸ ਲਈ ਨਾਮ ਮੈਚਿੰਗ fancy ranking ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕੈਟੇਗਰੀ ਖੋਜ ਉਹਨਾਂ ਲਈ ਮਦਦਗਾਰ ਹੈ ਜੇ ਉਹ ਸਿਰਫ਼ ਕੰਮ ਜਾਣਦੇ ਹਨ (payments, messaging)।
ਫਿਲਟਰ ਉਹੀ ਮਨ-ਉਦੇਸ਼ ਦਰਸਾਉਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਤਿੰਨ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਵਰਤੋਂ ਦੇ ਕੇਸ ਕਵਰ ਕਰਦੇ ਹਨ:
ਲਿਸਟ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਗਰੂਪਿੰਗ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ। ਵੱਡੀ ਗਿਣਤੀ 'ਤੇ category grouping ਵਧੀਆ ਕੰਮ ਕਰਦਾ (CRM, Payments, Messaging)। ਪ੍ਰਸਿੱਧਤਾ ਵੀ ਵਰਤੋਂਯੋਗ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਬੇਸ ਦੇ ਅਨੁਸਾਰ ਹੈ, ਮਾਰਕੀਟਿੰਗ ਦੇ ਅਨੁਸਾਰ ਨਹੀਂ। ਇੱਕ ਪ੍ਰਵਾਨਤ ਡਿਫਾਲਟ: ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਪਹਿਲਾਂ ਇੰਤਰਗਰੱਫ ਦਿਖਾਓ, ਫਿਰ ਬਾਕੀ ਨੂੰ category ਨਾਲ ਸਮੂਹਬੱਧ ਕਰੋ।
ਇਹ ਵੀ ਯੋਜਨਾ ਬਣਾਓ ਕਿ “ਹਰ ਕੋਈ ਸਭ ਕੁਝ ਨਹੀਂ ਵੇਖੇਗਾ।” ਜੇ ਕੋਈ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕਿਸੇ ਫੀਚਰ ਫਲੈਗ ਜਾਂ ਯੋਜਨਾ ਟਿਅਰ 'ਤੇ ਹੈ, ਤਾਂ ਜਾਂ ਤਾਂ ਉਸਨੂੰ ਛੁਪਾਓ ਜਾਂ ਅਸਫਲ ਦਰਸਾਓ ("Business plan")। ਇੱਕ ਪੰਨਾ ਭਰ ਗ੍ਰੇ-ਆਉਟ ਕਾਰਡ ਵੇਖਾਉਣਾ ਬਚੋ — ਇਹ ਪੰਨੇ ਨੂੰ ਟੁਟਿਆ ਹੋਇਆ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਪرفਾਰਮੈਂਸ ਨੂੰ ਤੇਜ਼ ਰੱਖੋ: ਲਿਸਟ ਅਤੇ ਡੀਟੇਲ ਵੱਖ-ਵੱਖ ਲੋਡ ਟਰੀਟ ਕਰੋ। 30 ਭਾਰੀ ਕਾਰਡ ਇਕੱਠੇ renderer ਨਾ ਕਰੋ; paginate ਜਾਂ virtualize ਕਰੋ, ਅਤੇ ਡੀਟੇਲ ਲੋਡ ਸਿਰਫ਼ ਜਦ ਉਪਭੋਗੀ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਖੋਲ੍ਹੇ। ਡਾਇਰੈਕਟਰੀ ਸੰਖੇਪ ਖੇਤਰ ਦਿਖਾ ਸਕਦੀ ਹੈ (Slack: Connected, Google: Needs attention, Stripe: Not set up) ਜਦਕਿ ਡੀਟੇਲ ਪੇਜ ਪੂਰਾ connection history ਫ਼ੈਚ ਕਰੇ।
ਕਲਪਨਾ ਕਰੋ ਇਕ ਟੀਮ ਵਰਕਸਪੇਸ ਐਪ Pinework। ਇਸ ਵਿੱਚ ਦੋ ਰੋਲ ਹਨ: Admin ਅਤੇ Member. Admins ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕਨੈਕਟ ਅਤੇ ਸੈਟਿੰਗਸ ਬਦਲ ਸਕਦੇ ਹਨ। Members ਜੁੜੇ ਟੂਲ ਵਰਤ ਸਕਦੇ ਹਨ ਪਰ ਜੋੜ/ਹਟਾ ਨਹੀਂ ਸਕਦੇ।
Pinework ਦੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹਰ ਕਾਰਡ ਇੱਕ ਸਪਸ਼ਟ ਲੇਬਲ (Connected, Needs setup, Error), ਇੱਕ ਛੋਟਾ “ਇਹ ਕੀ ਕਰਦਾ ਹੈ” ਲਾਈਨ, ਅਤੇ ਸੈਟਅਪ ਪ੍ਰਗਤੀ ਜਿਵੇਂ “2 of 3 steps” ਦਿਖਾਉਂਦਾ ਹੈ। ਲੋਕ ਬਿਨਾਂ ਬਹੁਤ ਕਲਿੱਕ ਕੀਤੇ ਸਮਝ ਸਕਦੇ ਹਨ ਕਿਹੜਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਬਕਾਇਆ।
Slack ਸੂਚਨਾਵਾਂ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇੱਕ Admin Slack ਖੋਲ੍ਹ ਕੇ ਵੇਖਦਾ: Status: Connected, Setup: “3 of 3 steps.” Members ਵੀ Slack ਦੇਖ ਸਕਦੇ ਹਨ, ਪਰ ਮੁੱਖ ਐਕਸ਼ਨ disabled ਹੋ ਕੇ “Ask an Admin to manage” ਲਿਖਦਾ ਹੈ। ਜੇ Slack disconnect ਹੋ ਜਾਂਦਾ ਹੈ, Members ਨੂੰ ਵੀ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕੀ ਖਰਾਬ ਹੋਇਆ, ਪਰ reconnect ਕੰਟਰੋਲ ਉਨ੍ਹਾਂ ਲਈ ਨਾਹ ਹੋਣਗੇ।
Google ਕੈਲੰਡਰ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। Pinework ਦੋ ਵਿਭਾਗਾਂ ਲਈ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਕਈ connections ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। Google ਕਾਰਡ ਦਿਖਾਏਗਾ: Status: Connected (2 accounts). ਥੱਲੇ ਇੱਕ ਛੋਟੀ ਲਾਈਨ “Marketing Calendar” ਅਤੇ “Support Calendar” ਦਿਖਾਏਗੀ। ਡੀਟੇਲ ਪੇਜ ਦੋ ਵੱਖ-ਵੱਖ connections ਦਿਖਾਏਗਾ ਤਾਂ Admin ਇੱਕ ਨੂੰ ਹੀ ਰੱਦ ਕਰ ਸਕੇ।
Stripe ਬਿਲਿੰਗ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਆਮ ਅਧੂਰਾ ਸੈਟਅਪ ਇਹ ਹੈ: ਅਕਾਊਂਟ ਕਨੈਕਟ ਹੈ, ਪਰ webhooks ਮੇਂ ਹਨ। ਕਾਰਡ ਦਿਖਾਏਗਾ: Status: Needs setup, Progress: “2 of 3 steps,” ਤੇ ਇੱਕ ਵਾਰੰਟਿੰਗ ਜਿਵੇਂ “Payments may not sync.” ਡੀਟੇਲ ਵਿਉ ਬਾਕੀ ਬਚੇ ਹੋਏ ਸਟੈਪਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ:
ਇਸ ਨਾਲ ਉਹ ਪੇਚੀਦਾ ਹਾਲਤ ਟਲ ਜਾਂਦੀ ਹੈ ਕਿ “ਇਹ ਜੁੜਿਆ ਦਿਖਦਾ ਹੈ ਪਰ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।”
ਇਕ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਅਕਸਰ ਤਬ ਟੁੱਟਦੀ ਹੈ ਜਦ ਐਪ ਕੁਝ ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਤੋਂ ਦਰਜਨਾਂ ਉੱਤੇ ਵੱਧਦਾ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਕਦੇ “ਵੱਡੀ ਟੈਕ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਛੋਟੀਆਂ ਲੇਬਲਿੰਗ ਅਤੇ ਮਾਡਲਿੰਗ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਹਰ ਰੋਜ਼ ਲੋਕਾਂ ਨੂੰ ਗੁੰਝਨ ਵਿੱਚ ਪਾ ਦਿੰਦੀਆਂ ਹਨ।
ਇੱਕ ਆਮ ਮੁੱਦਾ “installed” ਅਤੇ “connected” ਨੂੰ ਮਿਲਾ ਦੇਣਾ ਹੈ। Installed ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ “ਤੁਹਾਡੇ ਵਰਕਸਪੇਸ ਵਿੱਚ ਉਪਲਬਧ”। Connected ਮਤਲਬ ਹੈ ਅਸਲ ਕ੍ਰੈਡੈਂਸ਼ਲ ਮੌਜੂਦ ਹਨ ਅਤੇ ਡੇਟਾ ਬਹਾਉਂਦਾ ਹੈ। ਜਦ ਇਹ ਦੋਨੋ ਮਿਲ ਜਾਂਦੇ ਹਨ, ਤਦ ਉਪਭੋਗੀ ਇਕ ਐਸੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਜੋ ਦਿਖਦਾ ਤਾਂ ਤਿਆਰ, ਪਰ ਪ੍ਰਭਾਵ ਵਿੱਚ ਨਹੀਂ।
ਹੋਰ ਗਲਤੀ ਬਹੁਤ ਸਾਰੇ ਸਥਿਤੀ ਰਾਜ਼ੀ ਲੇਬਲ ਬਣਾਉਣਾ ਹੈ। ਟੀਮ ਇੱਕ ਸਾਦਾ ਬੈਜ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਫਿਰ ਐਜ ਕੇਸਾਂ ਲਈ ਹੋਰ ਲੇਬਲ ਜੋੜੇ: pending, verifying, partial, paused, degraded, blocked, expiring, ਆਦਿ। ਸਮੇਂ ਨਾਲ ਉਹ ਲੇਬਲ ਪਰਭਾਵ ਤੋਂ drifting ਕਰ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਉਨ੍ਹਾਂ ਨੂੰ ਸਥਿਰ ਨਹੀਂ ਰੱਖਦਾ। ਇੱਕ ਛੋਟਾ ਸੈਟ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਹਕੀਕਤ ਵਿੱਚ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ Not connected, Connected, Needs attention।
ਛੁਪੀ ਹੋਈ ਪਰਮਿਸ਼ਨਾਂ ਵੀ ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਕਿਸੇ ਨੇ ਖਾਤਾ ਜੋੜਿਆ, ਫਿਰ ਬਾਦ ਵਿੱਚ ਪਤਾ ਲੱਗਿਆ ਕਿ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਨੇ ਵੱਡੀ ਪਹੁੰਚ ਲਈ ਮੰਗ ਕੀਤੀ ਸੀ। ਆਖਰੀ “Connect” ਕਦਮ ਤੋਂ ਪਹਿਲਾਂ scope ਸਪਸ਼ਟ ਦਿਖਾਓ, ਅਤੇ ਡੀਟੇਲ ਪੇਜ 'ਤੇ ਫਿਰ ਦਿਖਾਓ ਤਾਂ ਕਿ admins audit ਕਰ ਸਕਣ।
ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਸ ਨੂੰ ਕਈ connections ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਦੋ Slack workspaces, ਕਈ Stripe accounts, ਜਾਂ ਇੱਕ ਸਾਂਝਾ Google account ਨਾਲ ਨਿੱਜੀ ਅਕਾਊਂਟ। ਜੇ ਤੁਸੀਂ ਕਠੋਰ ਧਾਰਨਾ ਕਰੋਂਗੇ “ਇੱਕ ਇੰਟਿਗ੍ਰੇਸ਼ਨ = ਇੱਕ ਕਨੈਕਸ਼ਨ”, ਤਾਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਭਿਆਨਕ ਵਿਰੋਧੀ ਹੱਲਾਂ ਨੂੰ ਜਨਮ ਦਿਆਂਗੇ।
ਇਸ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:
ਲਿਸਟ ਦ੍ਰਿਸ਼ ਨੂੰ ਹਲਕਾ ਰੱਖੋ। ਜਦ ਤੁਸੀਂ ਉਸ ਵਿਚ ਲੌਗ, ਫੀਲਡ ਮੈਪਿੰਗ, ਅਤੇ ਲੰਬੀਆਂ ਵੇਰਵਿਆਂ ਭਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਸਕੈਨਿੰਗ ਧੀਮੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਲਿਸਟ ਨੂੰ ਨਾਮ, ਛੋਟਾ ਮਕਸਦ, ਅਤੇ ਸੈਟਅਪ ਪ੍ਰਗਤੀ ਲਈ ਰੱਖੋ। ਇਤਿਹਾਸ ਅਤੇ ਉੱਚ-ਸਤਹ ਦੀਆਂ ਸੈਟਿੰਗਸ ਨੂੰ ਡੀਟੇਲ ਪੇਜ 'ਤੇ ਰੱਖੋ।
ਇੱਕ ਸਕੇਲ ਕਰਨ ਵਾਲੀ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਇੱਕ ਸادہ ਮਾਡਲ ਅਤੇ ਇੱਕ ਸੱਚੀ UI ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜੇ ਉਪਭੋਗੀ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਤੁਰੰਤ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ, ਤਾਂ ਸਿਸਟਮ ਅਨੁਮਾਨਯੋਗ ਮਹਿਸੂਸ ਹੋਵੇਗਾ: ਕੀ ਜੁੜਿਆ ਹੈ, ਕੀ ਟੁੱਟਿਆ ਹੈ, ਅਤੇ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ?
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੈਕਲਿਸਟ:
ਅੱਗੇ: ਉਹ ਤਿੰਨ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ end-to-end ਮਾਡਲ ਕਰੋ: ਇੱਕ chat tool (OAuth), ਇੱਕ Google-ਸਟਾਈਲ account connection (OAuth with scopes), ਅਤੇ ਇੱਕ payments tool (API key plus webhooks). ਜੇ ਤੁਹਾਡਾ ਮਾਡਲ ਇਹ ਤਿੰਨ ਬਿਨਾਂ ਖ਼ਾਸ ਕੇਸਾਂ ਦੇ ਦਰਸਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਇਹ 30 ਤੱਕ ਸਕੇਲ ਕਰ ਲੈਂਦਾ ਹੈ।
ਇਸਨੂੰ ਇੱਕ ਕੰਟਰੋਲ ਪੈਨਲ ਵਜੋਂ ਦੇਖੋ, ਮਾਰਕੀਟਿੰਗ ਪੰਨਾ ਨਹੀਂ। ਹਰ ਕਾਰਡ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੇਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕਿਸ ਲਈ ਹੈ, ਕੀ ਇਹ ਅਜੇ ਚੱਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਕਲੌਤਾ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ। ਜੇ ਉਪਭੋਗੀ ਨੂੰ ਇਹ ਜਾਣਨ ਲਈ ਕਲਿੱਕ ਵੀ ਕਰਨਾ ਪੈਏ ਕਿ “ਕੀ ਇਹ ਜੁੜਿਆ ਹੈ?”, ਤਾਂ ਡਾਇਰੈਕਟਰੀ ਵੱਡੀ ਹੋਣ 'ਤੇ ਬੇਵੱਸ ਲੱਗੇਗੀ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਇਹ ਹੈ: ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਕਾਰਡ ਨੂੰ “ਇਹ ਕੀ ਹੈ”, “ਕੀ ਇਹ ਸਿਹਤਮੰਦ ਹੈ”, ਅਤੇ “ਹੁਣ ਕੀ ਕਰਨਾ” ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਾਮ + ਇੱਕ ਲਾਈਨ ਦੀ ਉਦੇਸ਼-ਰਾਹ, ਇਕ ਸਥਿਤੀ ਨਾਲ ਨਵਾਂ ਟਾਈਮਸਟੈਂਪ (ਆਖਰੀ ਸਿੰਕ/ਚੈਕ) ਅਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਜਿਸਦੀ ਕਾਰਵਾਈ ਸਥਿਤੀ ਮੁਤਾਬਕ ਬਦਲਦੀ ਹੈ। ਬਾਕੀ ਸਭ “Manage” ਪਿੱਛੇ ਰੱਖੋ ਤਾਂ ਕਿ ਸਕੈਨਿੰਗ ਤੇਜ਼ ਰਹੇ।
ਇਸ ਲਈ ਕਿ ਤੁਸੀਂ ਜੋ ਆਫਰ ਕਰਦੇ ਹੋ, ਉਸਨੂੰ ਉਸ ਕੋਲ ਛੱਡ ਦਿਓ ਜੋ ਵਰਕਸਪੇਸ ਨੇ ਐਨੇਬਲ ਕੀਤਾ ਹੈ ਅਤੇ ਜੋ ਸ਼ਨਾਖ਼ਤੀਆਂ ਮੌਜੂਦ ਹਨ। ਗਲੋਬਲ Integration (katalog), Install (ਵਰਕਸਪੇਸ ਵਿੱਚ ਐਨੇਬਲ), ਅਤੇ Connection (ਅਸਲ OAuth ਅਕਾਊਂਟ, API key ਜਾਂ webhook)। ਇਹ ਇਸ ਆਮ ਗਲਤੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜਿੱਥੇ “installed” ਅਤੇ “connected” ਮਿਲ ਜਾਂਦੇ ਹਨ।
ਅਸਲ ਟੀਮਾਂ ਅਕਸਰ ਇੱਕੋ ਪ੍ਰੋਵਾਇਡਰ ਲਈ ਕਈ ਬਾਹਰੀ ਅਕਾਊਂਟ ਲੋੜਦੇ ਹਨ — ਮਾਰਕੀਟਿੰਗ ਅਤੇ ਸਪੋਰਟ ਲਈ ਵੱਖ-ਵੱਖ Google ਕੈਲੰਡਰ, ਜਾਂ ਕਈ Stripe ਖਾਤੇ। ਇੱਕੋ Install ਹੇਠਾਂ ਕਈ Connections ਮਾਡਲ ਕਰਨਾ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ ਪਰ ਐਡਮਿਨ ਨੂੰ ਵਿਅਕਤੀਗਤ ਰਿਪੋਰਟਿੰਗ/ਰੱਦ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ।
ਛੋਟਾ ਸੈਟ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ: Not set up, In progress, Connected, Needs attention, Disabled। ਫਿਰ ਇਹ ਲੇਬਲ ਉਹਨਾਂ ਤੱਥਾਂ ਤੋਂ ਨਿਕਲੋ ਜੋ ਤੁਸੀਂ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ — ਟੋਕਨ ਵੈਧ ਹੈ, ਲੋੜੀਂਦੇ ਸਟੈਪ ਪੂਰੇ ਹੋਏ, ਆਖਰੀ ਸਫਲ ਸਿੰਕ ਆਦਿ। ਇਸ ਤਰ੍ਹਾਂ ਬੇਕਾਰ ਜਾਂ ਅਪ-ਟੂ-ਡੇਟ ਨ ਮਿਲਣ ਵਾਲੇ ਬੈਜ ਨਹੀਂ ਰਹਿੰਦੇ।
ਸੈਟਅਪ ਪ੍ਰਗਤੀ ਨੂੰ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਵਜੋਂ ਰੱਖੋ: ਲੋੜੀਂਦੇ ਸਟੈਪ ਅਤੇ ਇੱਛਾਛਿਕ ਸਟੈਪ। ਹਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਲਈ ਸਟੈਪ ਦੀ ਪਰਿਭਾਸ਼ਾ ਸੇਵ ਕੀਤੀ ਜਾਵੇ ਅਤੇ ਹਰ Install ਲਈ ਸਟੈਪ ਦੇ ਨਤੀਜੇ ਰੱਖੋ, ਤਾਂ UI ਕਹਿ ਸਕੇ “2 ਵਿੱਚੋਂ 3 ਲੋੜੀਂਦੇ ਸਟੈਪ ਪੂਰੇ”।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਣ ਰੋਲ ਨੀਤੀ ਰੱਖੋ ਜੋ ਹਰ ਥਾਂ ਲਾਗੂ ਹੋਵੇ, ਫਿਰ ਸਿਰਫ ਸੰਵੇਦਨਸ਼ੀਲ ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਲਈ ਵਾਧੂ ਚੈੱਕ ਸ਼ਾਮਿਲ ਕਰੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਪੈਦਾਵਾਰਾਂ ਲਈ, Admins ਸਮੱਥ ਹਨ, Managers ਬਹੁਤ ਸਾਰੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਸੈਟਅਪ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ Members ਹੁਣੇ-ਨਾਲ ਵਰਤ ਸਕਦੇ ਹਨ ਪਰ ਸੈਟਿੰਗ ਨਹੀਂ ਬਦਲ ਸਕਦੇ। ਭੁਗਤਾਨ ਜਾਂ ਪੇਰੋਲ ਵਗੈਰਾ ਲਈ ਇਕ ਸਿੰਗਲ “billing/payments admin” ਫਲੈਗ ਰੱਖੋ, ਮੁਕੰਮਲ ਨਵਾਂ ਰੋਲ-ਸਿਸਟਮ ਬਣਾਉਣ ਦੀ ਜਰੂਰਤ ਨਹੀਂ।
ਯੂਜ਼ਰ-ਦਿੱਖ ਵਾਲੀ ਕਨਫਿਗ ਸਧਾਰਣ ਡੇਟਾ ਵਿੱਚ ਰੱਖੋ। ਸਕੰਧਰੇਟ ਰਿਹਾਈ ਜਾਂ API keys ਨੂੰ ਇੱਕ ਸੀਕ੍ਰਟ ਸਟੋਰ ਜਾਂ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਫੀਲਡ ਵਿੱਚ ਰੱਖੋ ਜਿਸ ਤੇ ਕਠੋਰ ਐਕਸੇਸ ਕੰਟਰੋਲ ਹੋਵੇ। ਰਾ ਕੁੰਜੀਆਂ, authorization codes ਜਾਂ webhook payloads ਨੂੰ ਲਾਗ ਨਾ ਕਰੋ; ਸਿਰਫ ਸੁਰੱਖਿਅਤ ਮੈਟਾ-ਡੇਟਾ ਅਤੇ connection_id ਵਰਗੀਆਂ ਰਿਫਰੈਂਸਾਂ ਲਾਗ ਕਰੋ।
ਸੰਦੇਸ਼ ਸਾਫ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਕੀ ਹੋਇਆ, ਉਪਭੋਗੀ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਾਡੀ ਸਿਸਟਮ ਅਗਲਾ ਕੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗੀ। ਰਿਟ੍ਰਾਈਜ਼ ਉਹਨਾਂ ਹਾਲਤਾਂ ਲਈ ਜਿੱਥੇ ਉਪਭੋਗੀ ਖੁਦ ਨਹੀਂ ਠੀਕ ਕਰ ਸਕਦਾ (ਪ੍ਰੋਵਾਇਡਰ ਡਾਊਨ, ਨੈੱਟਵਰਕ)। ਐਥੇ ਉਦਾਹਰਨ: “Slack connection expired. Reconnect to continue syncing. We’ll retry automatically once you reconnect.” ਇਹ ਇੱਕ ਕੱਚੇ API error ਤੋਂ ਵਧੀਆ ਹੈ।
ਸਰਲ ਖੋਜ ਰੱਖੋ: ਪਹਿਲਾਂ ਪ੍ਰੋਵਾਈਡਰ ਦਾ ਨਾਮ, ਫਿਰ ਕੈਟੇਗਰੀ। ਫਿਲਟਰ ਉਹਨਾਂ ਮਨ-ਉਦੇਸ਼ਾਂ ਦੇ ਅਨੁਸਾਰ ਹੋਣ ਚਾਹੀਦੇ ਹਨ ਜਿਵੇਂ: Connected, Needs attention, Not set up। ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਵਿੱਚ catalog fields, status rules, ਅਤੇ setup steps ਪਹਿਲਾਂ ਡਰਾਫਟ ਕਰੋ ਤਾਂ ਕਿ ਜਨਰੇਟ ਕੀਤਾ UI ਅਤੇ ਬੈਕਐਂਡ ਸਥਿਰ ਰਹੇ।