You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Here's our scenario:
We have several projects, but here are a few examples:
Initially (when we only had the IT service desk), we created portal-only accounts via API and added the new account as a customer to the project via API. When we added Accounting, we added that project to the script so new portal accounts were added to both projects. Other than the hassle of populating the initial customers, this was doable.
As we've grown, however, this has become increasingly difficult. Therefore, I thought I'd start using organizations to solve this problem. I created two organizations:
The thought was that I could simply add the "Employees with Company Email" organization to the relevant projects and add both organizations to the HR project. Then, my script would only need to maintain the membership of those organizations. This dramatically simplifies the automated process but comes with all sorts of unintended problems.
For example, the "Share with" option when submitting a request via the portal is broken (the only options are No one or Everyone and searching for a specific customer doesn't work). This appears to be a known issue, which is unfortunate.
We could open up project access to the public, but we really don't want non-employees to be able to submit portal requests to our internal departments.
I'm curious if anyone else out there has solved this problem. I think I'm going to have to abandon the work I've done to use organizations and go back to individually-targeted access (adding each customer individually to each project).