Internal access (Full access) for Cloudworks to work on Selective access in Admin Portal

Adithya S
Adithya S
in Security and Tenant Administration Ideas

Hi Team,

At present for the cloudworks actions to read the lists with selective access, 'internal (full) access' must be enabled within the list, which is quite tough to do in a live production model without disturbing the user's access. It would be ideal and intuitive if the access was controlled externally either through the admin portal or through cloudworks settings.

 

adithyasathyanarayana_0-1629816015114.png

 

Thanks

Adithya

Tagged:
29
Up
29 votes

New · Last Updated

Comments

  • Hayk
    Hayk

    100% agree with the issue itself. We thought it was a bug at first and spent half a day sorting this out.

  • tomgilbert_*50206
    tomgilbert_*50206

    Agreed. Managing the "Internal" user's access in the native users list would be much more intuitive.

  • JJANIK
    JJANIK

    Also agreed. Setting up the access from list level is not user friendly or intuitive.

  • kjacokes
    kjacokes
    edited February 2023

    Adding some color here--

    What's especially frustrating about this is that you can only edit this access by going directly to the Grid View on the List itself. The "Internal (Full Access)" user is not available within the Users section of the Anaplan Model.

    This makes it unclear to most users that "Internal (Full Access)" is even a User. If this user type appeared in the Users section of the Anaplan Model, it would at least prompt a model builder to wonder "Hey, what is this user?" and they would be able to look it up in the Anaplan documentation.

    Also, the name "Internal (Full Access)" obscures that fact that this is the User that is running all CloudWorks jobs. For the uninitiated model builder, the only way to know "Oh, this process is being run by a special user, not my user account or another user's account!" is to look at model history after a scheduled CloudWorks process runs to see that the user running that process is called "Internal (Full Access)". Again, obvious in retrospect, but not obvious up front.

    A handful of proposals for the product team (#1, I would humbly submit is low-risk/low-effort and delivers ~70% of the value we're looking for):

    *Short Term*

    1. Show "Internal (Full Access)" in the Users section of the Anaplan Model.
    2. Rename "Internal (Full Access)" to "CloudWorks Scheduler" or something...I realize there are probably Product Management implications of this, but I feel like this would clarify who this user is and what that user is doing.
    3. Update Anaplan documentation to make it clear that when scheduling a CloudWorks process that the scheduled process will be run by "Internal (Full Access)" or, if you adopt the above recommendation, "CloudWorks Scheduler", and a reminder that it will run with their permissions. Basically, https://en.wikipedia.org/wiki/Poka-yoke. This would also be great if you could include an informational message in the CloudWorks configuration dialog box itself that this process will be run by the "Internal (Full Access)" user.

    *Long Term*

    A) Make it possible to use "Run As..." in CloudWorks scheduler, so that you can choose the user account that will run a job, and the process will run using their security. Similarly to how Windows Task Scheduler Works.

    B) Let individual tasks be run by specific users, and have an Integration Orchestration Admin user (or something) orchestrate the execution of those jobs.


    Thanks for your consideration and for all you do!

    Kevin

  • AshwinK
    AshwinK

    Thanks for the feedback and support everyone. This maybe related, and of interest. We recently launched the support for Restricted Integration User ("RIU"). More details: https://help.anaplan.com/c0adc491-7e29-42ee-8b9f-c0bed95affd9-CloudWorks-management-for-restricted-integration-users

     Key benefits of this feature:

    1. With RIU, the permissions of the user running the integration is applied unlike an Integration Admin.
    2. RIUs can only create connections and integrations tied to the workspaces that have been assigned to.

     

  • Adithya S
    Adithya S

    @AshwinK but does this solve the problem of a list being used in an export with Selective access enabled? The premise of this issue is that if there a selective access enabled on a list and the cloud works in exporting data into AWS or Azure blob then it is an empty file as the 'Internal User (Full Access)' is not enabled in the list which has selective access!

  • kjacokes
    kjacokes

    Thanks so much for the clarity @AshwinK!

    @Adithya S, your understanding is my understanding, but won't speak for @AshwinK.

    What I suspect is happening here is that it is a "feature" to have the the Internal (Full Access) user i.e., the CloudWorks user, be an unnamed user that can be scheduled to run integrations on a regular basis. It's a feature because you're not paying for an additional user license, and it is an unnamed user so that if someone leaves the organization and their email is deactivated, the integration will still run as scheduled if it was set up by an Integration Admin.

    The only thing you have to do, of course, is make sure you go to the List's Grid View to add the Internal (Full Access) user to the list's selective access.

    And the new RIU is set up to enable any user to create integrations that run irrespective of the above, so essentially working as lots of us (including myself) had originally expected integration security to be handled (named user basis).

  • AshwinK
    AshwinK

    @Adithya S and @kjacokes thanks for your kind comments. Please refer to this documentation link: https://help.anaplan.com/f1ea0d39-4136-469f-a663-34a6aa96e7ae-Assign-Restricted-Integration-User-role-and-workspaces

    • If Dynamic Cell Access is enabled when an integration is run by a restricted integration user, the integration uses the permissions associated with that user.
    • If Selective Access is enabled for a list: 
      • The appropriate read/write permissions must be enabled for the restricted integration user. 
      • The restricted integration user doesn't use the permissions from the Internal (Full Access) alias (role).


Get Started with Idea Exchange


See our Submission Guidelines and Idea Evaluation Criteria, then start posting your own ideas and showing support for others!



Categories