ہر کلائنٹ کے لیے ایک سسٹم، یا ہر کلائنٹ کے لیے ایک پلیٹ فارم۔ آرکیٹیکچر طے کرتا ہے کہ آپ کیسے بڑھتے ہیں۔

ملٹی ٹیننٹ ڈائلر بہت سے کلائنٹس — یعنی ٹیننٹس — کو ایک مشترکہ پلیٹ فارم سے خدمت دیتا ہے۔ ہر ٹیننٹ صرف اپنی کیمپینز، رابطے، ایجنٹس، ریکارڈنگز اور رپورٹس دیکھتا ہے، لیکن تمام ٹیننٹس ایک ہی بنیادی ایپلیکیشن پر چلتے ہیں۔ آئسولیشن ہر کلائنٹ کو الگ ہارڈویئر دینے کے بجائے منطقی طور پر نافذ ہوتی ہے۔ درست طریقے سے کیا جائے تو کوئی ٹیننٹ کبھی دوسرے ٹیننٹ کا ڈیٹا نہ دیکھ سکتا ہے نہ اس تک پہنچ سکتا ہے۔

DialerBee اپنی ساخت ہی سے ملٹی ٹیننٹ ہے اور ڈیٹا لیئر پر آئسولیشن نافذ کرتا ہے۔ ہر ریکارڈ ٹیننٹ کی شناخت رکھتا ہے، اور رسائی اس طرح محدود ہے کہ کوئریز صرف درخواست کرنے والے ٹیننٹ کی رو ہی واپس کر سکتی ہیں — یہ طریقہ عموماً PostgreSQL رو لیول سیکیورٹی جیسے ڈیٹا بیس میکانزمز سے نافذ کیا جاتا ہے۔ اس کا مطلب ہے کہ کلائنٹس کے درمیان علیحدگی صرف ایپلیکیشن کوڈ پر نہیں چھوڑی جاتی بلکہ خود ڈیٹا پلیٹ فارم نافذ کرتا ہے۔

BPO یا ری سیلر کے لیے آپریشنل فائدہ فیصلہ کن ہے۔ نئے کلائنٹ کو آن بورڈ کرنا انفراسٹرکچر پراجیکٹ نہیں بلکہ کنفیگریشن کا ایک قدم ہے۔ اپ گریڈز، سیکیورٹی پیچز اور نئے فیچرز ایک ساتھ ہر ٹیننٹ تک پہنچتے ہیں۔ آپ کو مانیٹر اور برقرار رکھنے کے لیے ایک پلیٹ فارم ملتا ہے جبکہ ہر کلائنٹ کو مکمل طور پر الگ، قابلِ برانڈنگ ورک اسپیس ملتی ہے۔ یہی چیز ملٹی ٹیننٹ آرکیٹیکچر کو متعدد کلائنٹس کے لیے آؤٹ باؤنڈ کالنگ سنبھالنے والے ہر شخص کے لیے فطری انتخاب بناتی ہے۔ دیکھیں ہمارا ملٹی ٹیننٹ فیچر مکمل تفصیل کے لیے۔

بہت سے کلائنٹس کے لیے آؤٹ باؤنڈ کالنگ سنبھالنے والے اداروں کے لیے ملٹی ٹیننٹ آرکیٹیکچر درست ڈیفالٹ ہے، لیکن سنگل ٹیننٹ متروک نہیں۔ کچھ صورتوں میں مخصوص انسٹینس بہتر انتخاب رہتی ہے۔

اگر کوئی کلائنٹ ڈیٹا ریزیڈنسی یا معاہداتی شرط کے تحت کام کرتا ہے جس میں جسمانی طور پر مخصوص انفراسٹرکچر درکار ہو، تو سنگل ٹیننٹ تنصیب براہِ راست یہ شرط پوری کر سکتی ہے۔ یہی بات تب بھی لاگو ہوتی ہے جب کسی کلائنٹ کو بنیادی سسٹم کی ایسی گہری، مخصوص حسبِ ضرورت تبدیلی درکار ہو جو مشترکہ پلیٹ فارم پر لاگو کرنا مناسب نہ ہو۔

جو ادارے صرف ایک کلائنٹ کو خدمت دیتے ہیں — یا خود ہی واحد اختتامی صارف ہیں — انہیں ملٹی ٹیننسی سے کم فائدہ ہوتا ہے، کیونکہ الگ کرنے کے لیے کوئی دوسرا ٹیننٹ ہی نہیں۔ ایسی صورتوں میں ایک ماحول کی آپریشنل سادگی مشترکہ پلیٹ فارم کے فوائد پر مکمل طور پر بھاری پڑ سکتی ہے۔

باقی سب کے لیے — وہ BPOs، ٹیلی کام ری سیلرز اور ایجنسیاں جو باقاعدگی سے کلائنٹس شامل کرتی ہیں اور فی کلائنٹ بوجھ کے بغیر فی کلائنٹ علیحدگی چاہتی ہیں — ایک اچھی طرح بنایا گیا ملٹی ٹیننٹ پلیٹ فارم الگ سسٹمز کی آئسولیشن ایک سسٹم کی کارکردگی کے ساتھ فراہم کرتا ہے۔ DialerBee اسی توازن کے گرد ڈیزائن کیا گیا ہے، اور اسی لیے ہمارا BPO سلوشن اور وائٹ لیبل ڈائلر پلیٹ فارم ملٹی ٹیننٹ بنیادوں پر بنے ہیں۔

DialerBee اپنی ساخت ہی سے ملٹی ٹیننٹ ہے۔ آئسولیشن PostgreSQL رو لیول سیکیورٹی کے ساتھ ڈیٹا بیس لیئر پر نافذ ہوتی ہے، اس لیے ہر کوئری درخواست کرنے والے ٹیننٹ تک محدود ہوتی ہے اور ٹیننٹس کے درمیان رسائی ایپلیکیشن منطق کے بجائے ڈیٹا بیس انجن روکتا ہے۔ ہر ٹیننٹ کے اپنے تعمیل کے قواعد، آزاد ریٹینشن اور لیگل ہولڈ کنٹرولز والی اپنی ریکارڈنگز، اپنے استعمال اور بلنگ کی تخصیص، اور اپنی برانڈنگ ہوتی ہے۔ نئے ٹیننٹس ایڈمن پورٹل یا پارٹنر API کے ذریعے منٹوں میں فراہم کیے جاتے ہیں۔ تفصیل یہاں ہے: ملٹی ٹیننٹ آرکیٹیکچر کا صفحہ.

رسائی ایسی چیز ہے جو آپ اندازے کے بجائے گرڈ سے پڑھ سکتے ہیں: 11 اجازتی زمروں اور 41 اجازتوں کا فی ٹیننٹ رول میٹرکس، کارروائی، صارف اور متعلقہ IP ایڈریس ریکارڈ کرنے والا آڈٹ لاگ، محفوظ حالت میں ہیش شدہ اور اپنے ٹیننٹ تک محدود API کیز، اور پارٹنر ایڈمنز جو صرف اپنے ٹیننٹس دیکھتے ہیں۔ اس کی تفصیل یہاں ہے: سیکیورٹی اور رسائی۔ پلیٹ فارم اور پارٹنر ایڈمنسٹریٹرز کو بھی ملتا ہے آپریشنز سینٹر سروس کی صحت، لائیو کالز اور ابتدا سے انتہا تک کال ٹریس کے ساتھ، جبکہ ٹیننٹ ایڈمنسٹریٹرز صرف اپنا ٹیننٹ دیکھتے ہیں۔