Now, I am trying to set up a workflow that would re-run this refresh token API call periodically, to store the access_token for further use with other Dropbox API calls.
However, I’m getting stuck here and it does not appear to be working in my attempt… here are some screenshots of what I currently have in my workflow:
From reading the instructions, it seems like what I have here should cause the workflow to run every 60 seconds, refreshing the token value in the database, yet this does not seem to be happening…
Can anyone help me understand where I’m going wrong here? Thanks so much.
It looks like it should work. Did you check the logs? You may consider storing the response of Dropbox - Get Token in a log for debugging purposes and error handling.
Seems that the logs are completely empty…? Is there something I need to do in order to activate this workflow? I deployed the change to “Live” but seems like there is still no difference.
“Dropbox - Get Token” action will have responses available that can be saved in a log dataset or used in a list of texts somewhere. Did you initialize “Dropbox - Get Token”? Can you show me how it’s set up in API connector?
1 - Done
2 - It is set to Use As Action
3 - I do see the result of Step 1, but I don’t know where to find this option to store it in a log or anything like that
The result is exposed in the entire WF so any step can access it and store it (e.g., Create a new thing of type Log, Response code = results of step 1 response code, Error? = results of step 1 is_error.
Seems like the problem is more that this is never running at all. Is there some way I need to kick off the initial run so that the recursive scheduling process can happen?
Yes, I assumed your first screenshot below was triggering the WF but that certainly needs to happen first. You can set a button on a page or any other click or elements to trigger the initial call of the WF.
WARNING: This recurring Wf will costs you thousands in WU consumption. Add a Loop Max Runs # parameter to the workflow and increment the # in each reloop
Ahh yes, thank you this is was the problem. I decided to go with Bubble’s native file storage instead of Dropbox in this case, but good to know how the recursive workflow functions.
It does seem like the necessity of client-side scheduling of the workflow should be mentioned in the documentation, which makes it seem like it’s a purely server-side solution for recurring workflows.