Pamamahala ng maraming kliyente

Pinaghihiwalay ng karamihan sa mga team ang mga kliyente sa pamamagitan ng pag-iingat. Isang shared account ang may hawak ng bawat konektadong page, isang kalendaryo ang may hawak ng bawat iskedyul, at ang tanging humaharang sa isang draft ng kliyente at maling audience ay ang taong nakatingin sa screen alas-sais ng gabi. Kapag umalis ang isang tao sa team, umaalis din ang paghihiwalay kasama ng gawi nito.

• Ang proyekto ay ang unit ng paghihiwalay. Ang mga konektadong account, draft, queue, media, at resibo ay pag-aari ng isang proyekto, at nakikita lang ng miyembro ang mga proyektong kinabibilangan niya.
• Ipinapatupad ang paghihiwalay nang tatlong beses: sa authentication, sa application service na nagpapahintulot sa aksyon, at sa database mismo sa pamamagitan ng row level security. Hindi kailanman itinuturing na pahintulot ang pagiging naka-sign in.
• Sinusunod ng reporting ang parehong hangganan, kaya ang isang report kada kliyente ang default na hugis sa halip na isang spreadsheet na iaayos ng isang tao nang manwal.

Ang mga proyekto, ang membership na naka-scope sa proyekto, at ang mga row level security policy sa likod ng mga ito ay nagawa na at nasubok, kasama ang mga test na sumusubok magbasa sa pagitan ng mga proyekto at nagpapatunay na nabibigo ang mga ito. Sinusukat ang laki ng mga plano batay sa bilang ng proyektong kailangan ng isang team. Wala pang na-publish sa isang platform mula sa anumang proyekto.

Dala ng capability matrix ang bawat platform at bawat capability sa isang table. Inilalarawan ng mga page ng use case ang mga workflow na pinagbubuuan ng produktong ito.

Mga use case

Pag-iiskedyul, kada platform

Mga kakayahan sa platform