ਟੀਮਾਂ ਅਤੇ ਪਹੁੰਚ

ਆਪਣੀ ਟੀਮ ਦੇ ਹਰੇਕ ਵਿਅਕਤੀ ਨੂੰ ਉਹੀ ਪਹੁੰਚ ਦਿਓ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੈ

ਚਾਰ ਗਾਹਕ ਭੂਮਿਕਾਵਾਂ, ਉਪ-ਖਾਤੇ ਜੋ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਦੀ ਅਸਲ ਬਣਤਰ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਪ੍ਰਤੀ-ਸੰਸਥਾ API ਕੁੰਜੀਆਂ, ਸਿੰਗਲ ਸਾਈਨ-ਆਨ ਅਤੇ ਹਰੇਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੀ ਕਾਰਵਾਈ ਪਿੱਛੇ ਇੱਕ ਆਡਿਟ ਲੌਗ। ਇਹੀ ਪਹੁੰਚ ਮਾਡਲ ਡੈਸ਼ਬੋਰਡ, API, CLI, Terraform ਅਤੇ ਸਾਡੇ MCP ਸਰਵਰ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਪਲਬਧਤਾ: Terraform ਪ੍ਰਦਾਤਾ ਸਰਗਰਮ ਵਿਕਾਸ ਅਧੀਨ ਹੈ ਅਤੇ ਅਜੇ ਉਪਲਬਧ ਨਹੀਂ ਹੈ। ਇੱਥੇ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਬਾਕੀ ਸਭ ਕੁਝ ਅੱਜ ਲਾਈਵ ਹੈ।

ਇੱਕੋ ਖਾਤੇ ਨਾਲ ਜੁੜੇ ਕਈ ਲੋਕ, ਹਰੇਕ ਕੋਲ ਆਪਣੀਆਂ ਨਿਰਧਾਰਿਤ ਇਜਾਜ਼ਤਾਂ ਹਨ।
  • 7,00,000+ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਹੋਸਟ ਕੀਤੀਆਂ ਸਾਈਟਾਂ
  • 4ਗਾਹਕ ਭੂਮਿਕਾਵਾਂ, ਸੀਡ ਕੀਤੀਆਂ ਗਈਆਂ ਅਤੇ ਤਿਆਰ
  • 35ਵਿਸਤ੍ਰਿਤ ਇਜਾਜ਼ਤ ਕੁੰਜੀਆਂ
  • 14 ਦਿਨਕਾਰਡ ਰਹਿਤ ਅਜ਼ਮਾਇਸ਼

ਚਾਰ ਭੂਮਿਕਾਵਾਂ, ਜਿੱਥੇ ਕੰਮ ਅਸਲ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਉੱਥੇ ਨਿਰਧਾਰਤ

ਪਹੁੰਚ ਇੱਕ ਸਾਧਾਰਨ ਚਾਲੂ/ਬੰਦ ਸਵਿੱਚ ਨਹੀਂ ਹੈ। ਹਰੇਕ ਗਾਹਕ ਸੰਸਥਾ ਚਾਰ ਭੂਮਿਕਾਵਾਂ ਦੇ ਨਾਲ ਆਉਂਦੀ ਹੈ, ਹਰ ਇੱਕ ਵਿਸਤ੍ਰਿਤ module.action ਅਧਿਕਾਰਾਂ ਦਾ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬੰਡਲ ਹੈ — ਤਾਂ ਜੋ ਇੱਕ ਵਿੱਤ ਸੰਪਰਕ ਕਦੇ ਵੀ ਸਰਵਰ ਨੂੰ ਨਾ ਛੂਹੇ ਅਤੇ ਇੱਕ ਡਿਵੈਲਪਰ ਕਦੇ ਵੀ ਕੋਈ ਚਲਾਨ ਨਾ ਦੇਖੇ।

ਮਾਲਕ

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

ਬਿਲਿੰਗ ਮੈਨੇਜਰ

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

ਡਿਵੈਲਪਰ

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

ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ

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

ਉਪ-ਖਾਤੇ ਜੋ ਤੁਹਾਡੇ ਅਸਲ ਢਾਂਚੇ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ

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

ਭੂਮਿਕਾਵਾਂ ਸੰਸਥਾ ਪ੍ਰਤੀ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਲਾਗੂਕਰਨ ਵੀ ਸੰਸਥਾ ਪ੍ਰਤੀ ਹੀ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸੰਸਥਾ ਵਿੱਚ ਇੱਕ ਭੂਮਿਕਾ ਕਿਸੇ ਵੱਖਰੀ, ਗੈਰ-ਸੰਬੰਧਿਤ ਸੰਸਥਾ ਵਿੱਚ ਕੋਈ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ — ਇੱਕ ਠੇਕੇਦਾਰ ਉਸੇ ਲੌਗਇਨ ਤੋਂ ਇੱਕ ਗਾਹਕ ਖਾਤੇ 'ਤੇ ਡਿਵੈਲਪਰ ਅਤੇ ਦੂਜੇ 'ਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ (Read-only) ਹੋ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਪਹੁੰਚ ਤੁਹਾਡੇ ਆਪਣੇ ਲੜੀਵਾਰ ਢਾਂਚੇ ਦੇ ਹੇਠਾਂ ਵੱਲ ਜਾਂਦੀ ਹੈ: ਇੱਕ ਮੂਲ ਸੰਸਥਾ ਵਿੱਚ ਇੱਕ ਭੂਮਿਕਾ ਉਸ ਦੇ ਅਧੀਨ ਆਉਂਦੀਆਂ ਸੰਸਥਾਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਰੀਸੇਲਰ ਅਤੇ ਏਜੰਸੀਆਂ ਆਪਣੇ ਗਾਹਕਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੀਆਂ ਹਨ।

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

ਹਰੇਕ ਸਤ੍ਹਾ 'ਤੇ ਇੱਕੋ ਜਿਹੀਆਂ ਇਜਾਜ਼ਤਾਂ

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

ਡੈਸ਼ਬੋਰਡ

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

ਜਨਤਕ API ਅਤੇ CLI

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

Terraform ਪ੍ਰਦਾਤਾ

ਸਾਈਟਾਂ, ਡੋਮੇਨਾਂ, DNS, ਮੇਲਬਾਕਸਾਂ ਅਤੇ ਪਲਾਨਾਂ ਨੂੰ ਇਨਫਰਾਸਟ੍ਰਕਚਰ-ਐਜ਼-ਕੋਡ ਵਜੋਂ ਪ੍ਰਬੰਧਿਤ ਕਰੋ ਅਤੇ ਹੋਸਟਿੰਗ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨ ਲਈ terraform apply ਚਲਾਓ — ਬਾਕੀ ਸਭ ਕੁਝ ਵਾਂਗ ਸਮਾਨ ਸਕੋਪਾਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ।

MCP ਸਰਵਰ

Claude Code, Cursor, ChatGPT, Claude Desktop ਜਾਂ ਕਿਸੇ ਵੀ MCP-ਸਮਰੱਥ ਟੂਲ ਨੂੰ ਕਨੈਕਟ ਕਰੋ। ਟੋਕਨ ਕਿਸੇ ਸੰਸਥਾ ਅਤੇ ਇਸਦੀਆਂ RBAC ਅਨੁਮਤੀਆਂ ਤੱਕ ਸੀਮਿਤ ਹਨ, ਪ੍ਰਤੀ ਟੂਲ ਰੱਦ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਨੁਕਸਾਨਦੇਹ ਕਾਰਵਾਈਆਂ 'ਤੇ ਪੁਸ਼ਟੀਕਰਨ, ਖਰਚ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਇੱਕ ਪੂਰੇ ਆਡਿਟ ਟ੍ਰੇਲ ਦੇ ਨਾਲ।

ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ

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

ਇੱਕ ਲੌਗਇਨ, ਮਿਆਰਾਂ 'ਤੇ ਅਧਾਰਤ, ਸਭ ਕੁਝ ਵਿੱਚ

ਪਛਾਣ Keycloak 'ਤੇ ਚੱਲਦੀ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਹੋਸਟਿੰਗ ਪੈਨਲ 'ਤੇ ਜੋੜੇ ਗਏ ਕਿਸੇ ਕਸਟਮ ਲੌਗਇਨ ਫਾਰਮ ਦੀ ਬਜਾਏ ਉਚਿਤ OIDC ਅਤੇ SAML ਹੈ।

  • ਮੂਲ ਰੂਪ ਵਿੱਚ ਮੈਜਿਕ-ਲਿੰਕ ਈਮੇਲ ਲੌਗਇਨ, ਅਤੇ ਇਸਨੂੰ ਤਰਜੀਹ ਦੇਣ ਵਾਲੇ ਲੋਕਾਂ ਲਈ ਬਦਲ ਵਜੋਂ ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ।
  • ਫਿਸ਼ਿੰਗ-ਰੋਧਕ ਸਾਈਨ-ਇਨ ਲਈ ਪਾਸਕੀਜ਼ ਅਤੇ WebAuthn, ਨਾਲ ਹੀ ਨੀਤੀ ਦੁਆਰਾ ਸਾਰਿਆਂ ਲਈ ਲਾਜ਼ਮੀ ਕੀਤਾ ਗਿਆ TOTP ਦੋ-ਪੜਾਵੀ ਪ੍ਰਮਾਣੀਕਰਨ।
  • Google, Microsoft, GitHub ਅਤੇ ਹੋਰ ਪਛਾਣ ਪ੍ਰਦਾਤਿਆਂ ਰਾਹੀਂ ਸੋਸ਼ਲ ਲੌਗਇਨ।
  • ਐਂਟਰਪ੍ਰਾਈਜ਼ ਅਤੇ ਏਜੰਸੀ ਗਾਹਕਾਂ ਲਈ SAML ਸਿੰਗਲ ਸਾਈਨ-ਆਨ, ਤਾਂ ਜੋ ਟੀਮ ਦੀ ਪਹੁੰਚ ਤੁਹਾਡੀ ਮੌਜੂਦਾ ਡਾਇਰੈਕਟਰੀ ਦੀ ਪਾਲਣਾ ਕਰੇ।
  • ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਕੰਸੋਲ, ਜਨਤਕ ਸਾਈਟ ਅਤੇ ਗਿਆਨ ਕੋਸ਼, ਅਤੇ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਵਿੱਚ ਇੱਕ ਹੀ ਸੈਸ਼ਨ — ਪੰਜ ਵਾਰ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਸਾਈਨ ਇਨ ਕਰੋ।
  • ਖਾਤਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਸਾਈਨ-ਅੱਪ ਈਮੇਲ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਡਿਲੀਵਰ ਨਾ ਹੋਣ ਯੋਗ ਅਤੇ ਅਵੈਧ ਪਤੇ ਕਦੇ ਵੀ ਤੁਹਾਡੀ ਟੀਮ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ।
  • ਕਿਉਂਕਿ ਇਹ ਮਾਪਦੰਡਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਇਸ ਲਈ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਨੂੰ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਬਿਨਾਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ — ਉਹੀ ਨੋ-ਲਾਕ-ਇਨ ਨਿਯਮ ਜੋ ਅਸੀਂ ਹਰ ਦੂਜੇ ਵਿਕਰੇਤਾ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਾਂ।

ਜਵਾਬਦੇਹੀ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਆਡੀਟਰ ਨੂੰ ਸੌਂਪ ਸਕਦੇ ਹੋ

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

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

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

ਇਜਾਜ਼ਤਾਂ ਤੁਹਾਡੇ ਨਾਲ ਕਿਵੇਂ ਵਧਦੀਆਂ ਹਨ

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

  • ਅੱਜ 35 ਵਿਸਤ੍ਰਿਤ module.action ਕੁੰਜੀਆਂ, ਜੋ ਸੰਸਥਾਵਾਂ, ਮੈਂਬਰਾਂ, API ਕੁੰਜੀਆਂ, ਸਾਈਟਾਂ, ਬਿਲਿੰਗ, ਪਲਾਨਾਂ, ਫਲੀਟ, ਟਿਕਟਾਂ, ਗਾਹਕਾਂ, ਦੁਰਵਰਤੋਂ, ਮੁਹਿੰਮਾਂ, ਅਨੁਵਾਦਾਂ ਅਤੇ ਆਡਿਟ ਵਿੱਚ ਫੈਲੀਆਂ ਹੋਈਆਂ ਹਨ।
  • ਹਰੇਕ ਡਿਪਲਾਇਮੈਂਟ 'ਤੇ ਕੈਟਾਲਾਗ ਨੂੰ ਆਈਡੈਂਪੋਟੈਂਟ ਤਰੀਕੇ ਨਾਲ ਸੀਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਕੋਈ ਭੂਮਿਕਾ ਕਦੇ ਅਜਿਹੀ ਇਜਾਜ਼ਤ ਦਾ ਹਵਾਲਾ ਦਿੰਦੀ ਹੈ ਜੋ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ — ਟਾਈਪਿੰਗ ਦੀ ਗ਼ਲਤੀ ਚੁੱਪਚਾਪ ਕੁਝ ਵੀ ਨਾ ਦੇਣ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣ ਸਕਦੀ।
  • ਨਵੀਆਂ ਉਤਪਾਦ ਸਮਰੱਥਾਵਾਂ ਐਂਡਪੁਆਇੰਟ ਦੇ ਜਾਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕੈਟਾਲਾਗ ਵਿੱਚ ਆਪਣੀਆਂ ਇਜਾਜ਼ਤ ਕੁੰਜੀਆਂ ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਲਾਈਵ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਨੂੰ ਕਦੇ ਵੀ ਪਿਛੋਕੜ ਤੋਂ ਸ਼ਾਮਲ ਨਾ ਕਰਨਾ ਪਵੇ।
  • ਇੱਕਹਿਰੀ ਮੈਂਬਰਸ਼ਿਪ ਦੇ ਦਾਇਰੇ ਨੂੰ ਖਾਸ ਸਾਈਟਾਂ ਜਾਂ ਕਿਸੇ ਖਾਸ ਖੇਤਰ ਤੱਕ ਸੀਮਤ ਕਰਨਾ ਇੱਕ ਯੋਜਨਾਬੱਧ ਸੁਧਾਰ ਹੈ, ਇਹ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਅੱਜ ਹੀ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ। ਮੌਜੂਦਾ ਤਰੀਕਾ ਇਹਨਾਂ ਸਾਈਟਾਂ ਨੂੰ ਇੱਕ ਅਧੀਨ ਸੰਸਥਾ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ ਉਸ ਵਿਅਕਤੀ ਨੂੰ ਉੱਥੇ ਇੱਕ ਭੂਮਿਕਾ ਦੇਣਾ ਹੈ — ਜੋ ਤੁਹਾਨੂੰ ਕਿਰਾਏਦਾਰੀ ਲੜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹੀ ਵਿਭਾਜਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
  • API ਕੁੰਜੀਆਂ ਪ੍ਰਤੀ ਵਿਅਕਤੀ ਦੀ ਬਜਾਏ ਸੰਸਥਾ ਦੇ ਪੱਧਰ 'ਤੇ ਜਾਰੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਏਕੀਕਰਣ ਲਈ ਇਹਨਾਂ ਨੂੰ ਸੇਵਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਮੰਨੋ ਅਤੇ ਮਨੁੱਖੀ ਪਹੁੰਚ ਲਈ ਮੈਂਬਰਸ਼ਿਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

ਹਰੇਕ ਭੂਮਿਕਾ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦੀ ਹੈ?

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

ਕੀ ਮੈਂ ਕਿਸੇ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਾਈਟ ਦੀ ਪਹੁੰਚ ਦੇ ਸਕਦਾ ਹਾਂ?

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

ਕੀ API ਕੁੰਜੀਆਂ ਵਿਅਕਤੀਗਤ ਟੀਮ ਦੇ ਮੈਂਬਰਾਂ ਨਾਲ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ?

ਨਹੀਂ — API ਕੁੰਜੀਆਂ ਪ੍ਰਤੀ ਸੰਸਥਾ ਜਾਰੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ RBAC ਇਜਾਜ਼ਤਾਂ ਨਾਲ ਜੁੜੇ ਵਿਸਤ੍ਰਿਤ ਦਾਇਰੇ ਅਤੇ ਵੱਖਰੇ sandbox ਅਤੇ live ਮੋਡ ਹੁੰਦੇ ਹਨ। ਏਕੀਕਰਣਾਂ, CI ਜਾਂ Terraform ਲਈ ਉਹਨਾਂ ਨੂੰ ਸੇਵਾ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਵਜੋਂ ਵਰਤੋ, ਅਤੇ ਲੋਕਾਂ ਲਈ ਮੈਂਬਰਸ਼ਿਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਹਰੇਕ ਕੁੰਜੀ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਹੈਸ਼ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਹਰੇਕ ਕੁੰਜੀ ਇਹ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਆਖਰੀ ਵਾਰ ਕਦੋਂ ਵਰਤੀ ਗਈ ਸੀ, ਅਤੇ ਕਿਸੇ ਵੀ ਕੁੰਜੀ ਨੂੰ ਆਪਣੇ ਆਪ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਕੀ ਕੋਈ ਡਿਵੈਲਪਰ ਲਾਈਵ ਸਾਈਟ 'ਤੇ ਤਬਦੀਲੀਆਂ ਪੁਸ਼ ਕਰ ਸਕਦਾ ਹੈ?

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

ਕੀ ਤੁਸੀਂ ਸਾਡੀ ਕੰਪਨੀ ਡਾਇਰੈਕਟਰੀ ਲਈ SSO ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹੋ?

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

ਮੈਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਕਿਸੇ ਨੇ ਕੁਝ ਬਦਲਿਆ ਹੈ?

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

ਕੀ ਟੀਮ ਮੈਂਬਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਮੇਰੇ ਦੁਆਰਾ ਭੁਗਤਾਨ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਰਕਮ ਬਦਲਦੀ ਹੈ?

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

ਕੀ ਮੈਂ ਵਚਨਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਅਜ਼ਮਾ ਸਕਦਾ ਹਾਂ?

ਹਾਂ। Footprint-Free ਟ੍ਰਾਇਲ 14 ਦਿਨਾਂ ਲਈ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਕਿਸੇ ਕਾਰਡ ਵੇਰਵੇ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਇਹ 5 ਸਾਈਟਾਂ ਤੱਕ ਕਵਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਕੁਝ ਵੀ ਭੁਗਤਾਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਸੰਸਥਾ ਸੈੱਟਅੱਪ ਕਰ ਸਕੋ, ਆਪਣੀ ਟੀਮ ਨੂੰ ਸੱਦਾ ਦੇ ਸਕੋ ਅਤੇ ਅਸਲ ਕੰਮ ਦੇ ਵਿਰੁੱਧ ਭੂਮਿਕਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕੋ। ਭੁਗਤਾਨ ਕੀਤੇ ਪਲਾਨਾਂ 'ਤੇ 30-ਦਿਨਾਂ ਦੀ ਪੈਸੇ ਵਾਪਸੀ ਦੀ ਗਾਰੰਟੀ ਹੈ।

ਟਿਕਟਾਂ ਰਾਹੀਂ ਨਹੀਂ, ਮਿੰਟਾਂ ਵਿੱਚ ਆਪਣੀ ਟੀਮ ਸੈੱਟ ਅੱਪ ਕਰੋ

Footprint-Free ਲਾਈਨ 'ਤੇ ਬਿਨਾਂ ਕਾਰਡ ਦੇ 14-ਦਿਨਾਂ ਦੀ ਅਜ਼ਮਾਇਸ਼ ਸ਼ੁਰੂ ਕਰੋ, ਆਪਣੀ ਟੀਮ ਨੂੰ ਸੱਦਾ ਦਿਓ, ਅਤੇ ਕੋਈ ਵੀ ਭੁਗਤਾਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਸਾਈਟਾਂ 'ਤੇ ਭੂਮਿਕਾਵਾਂ ਦੇ ਕੰਮਕਾਜ ਨੂੰ ਦੇਖੋ।

ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ