CloudWorks - Model to Model Processes

I am trying to schedule automated Model-to-Model processes using CloudWorks so that it doesn't have to be done manually by a human. What I've noticed is some of my Actions within the automated Process don't run properly when CloudWorks runs it vs. when I manually run it. 

It seems that Cloudworks, "Internal (Full Access)", is leaving off a couple of imports at the bottom. 

 

The Action "Clear MyAccess Roles for L2 & L3 Resets" is a Delete List Using Selection. It seems to complete this, but then doesn't do the next 2 actions. 

 

Has anyone else seen errors like this? 

Answers

  • @ryane_galaton 

     

    I suggest checking the security access of the CloudWorks user....A very easy way to do this is to change the roll to Full Access and make sure that user has write access to all members in the hierarchy.  Also, something to think about, once you setup the cloudworks integration, did you go back and add actions to the process?  If so, wipe out the cloudworks process and recreate it.

     

    Rob

  • @rob_marshall 

     

    The CloudWorks user says "Internal (Full Access)". It doesn't have a user ID on the users tab so I wouldn't know where to grant the role as Full Access. The Data Integration Process was set up by me, who has Full Access to everything. 

     

    When I set up the CloudWorks integration, I did not go back and change/add/delete any of the actions within that Process. It's a finalized Process for now and shows as such in the CloudWorks > Integrations admin page. 

  • @ryane_galaton 

     

     

    I guess what confused me is the Internal (Full Access) bit and I thought that was a role that was set up within Anaplan.  I just set up a process containing two actions and it worked as expected.  Are you saying it didn't run the last two actions within the process or the deletion of members (Remove L4-> L1 along with the Clear Access)?

     

    2022-06-02_17-47-54.png

     

    Rob

  • @ryane_galaton 

    One possible reason could be an error with selective access. If there are lists in source with selective access enabled, you need to provide "Internal (Full Access)" a read access, otherwise it won't update the latest values.

     

    Checkout the page on common errors for more information.

    https://help.anaplan.com/f6f94935-6f97-4530-91fb-19ddc06a746c-Common-CloudWorks-errors-and-solutions

     

     

  • @rob_marshall @Nagaraju 

    It does look like the error is a selective access issue. I removed the check boxes under Selective Access for all lists L1 - L5. After doing that, it looks like the CloudWorks automation ran successfully, showing 200 Item(s) Added on history ID 2021669 (which was the action missing from the previous runs). 

     

    The weird thing is, I was under the assumption that the Dynamic Cell Access would not work on imports into the Users tab for security reasons, since it does not specify what exactly isn't supported for DCA. 

     

    The 2 imports that were not running were from the 2 CREATE modules, which are dimensioned by the CC Hierarchy Lists, L2 and L3. It's a little strange that these were impacted even though there are not DCA specific line items anywhere within the model. (It was strictly for testing purposes).

    This is a successful runThis is a successful runscreenshot from the Lists tabscreenshot from the Lists tabscreenshot from the Modules tabscreenshot from the Modules tab

    Saved View of L2 Business Area to ImportSaved View of L2 Business Area to Import

     

  • You do not need to remove selective access. In my testing, I imported data from a module in workspace A to a module in workspace B that had list formatted data with selective access applied that did not appear (and cloudworks process only partially succeeded) until I set the Internal (Full Access) in the TARGET list: 

    navigate to the target list grid view, and assign Internal (Full Access) to the top level parent in the READ column.

     

    ChrisStauffer_0-1660143781499.png

     

  • Quick addition to the solution above - I experienced the same issue recently. I had to add the Internal (full access) user to Read Access to SOURCE lists of the modules I was pulling the data from between models as well. Hope this helps.