Process Failure with CloudWorks



I am trying to automate a model to model import with cloudworks, the process fails and I am observing some strange behaviour

1. The same process runs for dev model but fails for prod model. Both models are in sync. While running the process manually, it completes successfully in both models.

2. My process has 4 actions in totals, however when I am viewing details of failure in cloudworks I can see only 3 actions, but if I click on edit, the 4 actions are intact.

Attaching the error screenshot



Does anyone has any idea on how to resolve this and what could be causing this error? Any help is appreciated


Thanks and Regards,

Aakash Sachdeva

Best Answer

  • aakash
    Answer ✓

    Hi @andrewtye @rob_marshall ,


    Thanks a lot for the help. I have found a solution (workaround) for this failure. This is going to be very helpful for anyone encountering this error where the same process runs in development model but not in deployed model using cloudworks. Had been investigating the cause of this failure and below are my findings. 

    Cause of the Issue

    1. When you create an import from the same model as source and target , and later sync this to target. The import data source is not populated correctly.

    2. After the sync , if you navigate to 'Import Data Source', for the same import in the Production Model , the column with the 'Source Model' would still have the name of Dev Model stored in it.

    3. When you run this import manually in the model itself, somehow the model recognizes that the import source and target are meant to be production model only, but the same import when ran through cloudworks would see this data source field (I assume) and it always tries to run the import considering the dev model as a source, which causes the issue here. I have checked , even the imports which are running fine only reflect the data coming in from Dev Model , not the Production Model. Since, this is the same model, you cannot even edit 'Source Data Models'. 



    1. Navigate to Dev Model , Mark these import data sources as production imports.

    2. Create a revision tag and sync to Production Model.

    3. Visit the Production Model and edit these sources to correctly reflect the production model, once that happens , the source Model field will become blank.

    4. Your process should work now using cloudworks.


    @rob_marshall , feel free to add to this and maybe we can add this to 'Known Issues and Workarounds'?


    Hope this is going to help others


    Aakash Sachdeva


  • @aakash 


    Quick question, from CloudWorks, are you using the same user ID?  My thinking is around security and your ID  has the appropriate security and the ETL user ID does not.



  • Hi @rob_marshall ,


    Thanks for the quick response. I am using the same user ID for both manually running the process and for using cloudworks. Also, I am able to run other processes for the same workspace and same user access.

  • Hi @aakash 

    We've got the same issue ... and it's a known problem with integrations within Cloudworks.

    This thread has the answer from @DibB ( and to them is there an update as to when it'll be deployed?


  • @aakash 


    That is a great call and it may in fact work, but in my eyes, it shouldn't BE the solution.  You said it best, it is a work around.  Let me see what I can find out about this on this side and will get back to you.


    Don't get me wrong, I am a huge of clean Import Sources, but making them Production Data is not correct.



  • I did think that this was possible but then remembered those sage words "just because you can doesn't mean you should"

    Hope the proper fix comes in soon.

  • We have put in a fix for the issue. Can you please let us know if the issue still exists?
  • Hello, 

    I have some Issue with cloudworks, my process works in dev model but not in depolyed model using cloudworks .

    Any solutions about this probleme plz!!

    for your solution "3. Visit the Production Model and edit these sources to correctly reflect the production model, once that happens , the source Model field will become blank." 

    How we can edit source ? 


  • @yassine26 


    Update the Dev model for the lists to be Production Data, take a revision, and then sync the revision to Prod.  Also, you might want to review this as well:



  • @rob_marshall 

    i already did it but it's not work, The process is working fine when run manually in deployed model but not works using cloudworks


    Thanks in advance 


  • aakash

    Hi @yassine26 ,


    Although I believe this issue has been resolved from Anaplan from the backend, but still, let me explain the third step to you in detail.

    3.a Under Actions -> Import Data Sources -> Check the column named 'Production Data' in Dev Model.

    3.b. Sync this to Production Model.

    3.c In production model, navigate to Actions -> Import Data Sources, for the concerned import action, click on Source Model cell and click on Edit and then click on OK without making any changes.

    3.d. The source model field for this particular import should now show as '-'.


    Hope, this helps, but this issue and resolution is specific to an import where the source model and target model is the same (you are running a model to model import within the same model).


    Some other debugging steps I can suggest you

    1. Please check the access roles setup, if the list you are importing to has selective access enabled, make sure your Workspace Administrator provides the user Internal (Full Access) with the correct Read permissions.

    2. Please check if the issue could be caused because of Dynamic Cell Access Involved. Can't recall exactly, but there might be some extra steps required there as well. @rob_marshall , feel free to confirm / correct me.




    Aakash Sachdeva



  • @yassine26 


    Do you know what the error is?  On the far right of the action/process, 3 little buttons will show up (I believe) and you can click Details.



  • Has any fix for this been found? We are running into this exact same issue.


    We've implemented the fix you describe, but we still receive the same error.