I’ve been spending the past month building out a bunch of automations and field calculations, and it hit me how easy it would be to accidentally lose all that work whether by deleting something by mistake or if something unexpected goes wrong. It would be really helpful to have an Export button in the Automations section, so we can back everything up and keep a local copy just in case. Same goes for app structure.
I know some people might use a third party for backups, but as someone who’s more security conscious, I’m not super comfortable giving out API access to external services. Having a built in option to export automations and app config directly from the platform would give a lot of peace of mind, not just to me, but probably to a lot of security conscious users.
This kind of feature feels more like a necessity than a nice to have. Losing hours,weeks,or months of work because of a small mistake on my end or system glitch would be painful, and an export feature would make a huge difference in preventing that.
I would like this functionallity as well.
Today I accidentally overwrite the script code inside an automation and hit Save. Old script gone!
Fortunatelly Claude remembered the code from an earlier session…
A feature to save the automations to an external location would be great. Exporting to another backup workspace would work for me too.
Partly. Revision history would definitely help in cases of typos, mistakes and accidently deleting or wrongly updates of an automation.
There is another reason for this. In a live production situation, I am reluctant to make updates to automations. I would like to test it first in a test environment. Copying automations from one environment (my test Organisation) to another (the live production organisation) is necessary for that.
How do you handle test/production environments with Tape?
@Erik_Mathlener - We have historically made copies of entire workspaces to use as a separate test/production environment.
Tape makes this quite easy to do at face value.
And this works fine for the uses that take place immediately for testing alternative options.
But please note that this approach has several potentially negative impacts that you need to keep in mind…
Any structural edits made (in either environment) after the clone event occurs will only be reflected on one side, not both.
If cloning without data, it can be hard to test some features in the test environment.
If cloning with data, it can lead to confusion for anyone with access to the test environment workspace as well as the production workspace. If they ever do a global search they would see what seems like duplicate results for all cloned records (such as contact names or project numbers from a CRM workspace clone)
Cloned automations may cause issues if left active.
We had some large hourly triggered flows that were cloned and inadvertently left on once. This caused thousands and thousands of unwanted automations to trigger and to cause automation throttling that impacted real users trying to work in the production environment.
You have to spend time either deleting or disabling all unwanted automations whenever cloning a new duplicate test environment.
I’m sure there are more that I’m missing here!
Recently we have found that the different layouts in the new record is a more viable option.
You can create a new layout and set it up with totally different fields, look, and feel.
(just be careful if your regular users are on the Main layout, they will see your new fields pop up at the bottom unless you deliberately go to the Main layout configuration and mark the new fields as hidden on that particular layout.)
Then for the automations, you can clone existing automations and use creative filters to make sure they don’t trigger except for when you want. This may look like a filter saying “only run when last edited by = your user”
Or a special field that is only visible to developers gets toggled to = test and the filter checks if that value is true before running the new version of the automation.
I know these are all somewhat workarounds rather than a true test versus production environment…but hopefully these ideas will get you closer to achieving what you want using the Tape features that are currently available.
I’m certainly curious to hear how others approach and solve this testing environment situation within Tape.
I agree that cloning to another workspace is the best option. Having real data available for testing is great.
I also see a risk that you might accidentally mess around in the live environment instead of the test environment. So it’s always a matter of paying close attention.
I’m still dealing with one small issue. In some automations, I use scripts that perform more complex operations, or that write data to HTML or PDF output (I do this by emailing those reports to the user. Not the best way, but I haven’t found another yet).
Sometimes I have no choice but to reference apps and fields in those scripts using hard-coded IDs. For example, in the call to getFieldValues. When I clone automations to another workspace, I obviously have to update those IDs. Is there a better way to do this?
@Erik_Mathlener - again, I don’t think there is a right answer, but I will make note here of how I handle that situation.
Whenever possible, I set up an app called ‘Automation Settings’ usually in a separate configuration or admin workspace that is part of the system.
Then, when I’m going through builds that require a hard-coded value, like you mentioned, I actually go edit the automation settings app and put in a new field specifically to house that information. In the automation, I just look up and call that variable. This way, when we clone systems, we don’t have to have notes saying, “Go look in these six different automations and update all of them.” We simply have one instruction to go into automation settings and validate all the fields there, and then any cloned automations will continue to work by using those variables.
That’s a great solution for handling hardcoded field ID’s. Thanks for the suggestion, I will use this method too.
Regarding the need to enable backups and test environments, I think cloning workspaces can work, although it doesn’t seem like the ultimate approach. I will test it in the next weeks. And I wonder what will happen if you clone a workspace in which apps have references (relations) to apps in another workspace. These references will probably still exist.
The situation will then be:
A.app1 links to B.app2
TEST-A.app1 links to B.app2
After cloning workspace B to TEST-B, the situation will probably be:
A.app1 links to B.app2
TEST-A.app1 links to B.app2
TEST-B.app2 is not referenced by any app.
What I want is:
A.app1 links to B.app2
TEST-A.app1 links to TEST-B.app2
Yes @Erik_Mathlener - your assumed reference configuration is correct.
When cloning workspaces with apps that cross workspace borders, you only get a new version of the apps included in the current workspace.
Therefore to achieve the result where
pre -clone A.app1 links to B.app2
post-clone TEST-A.app1 links to TEST-B.app2
My understanding is that you would either have to keep app 1 and app 2 in one shared workspace.
Or clone workspace A and B separately, then manually go back and change the relationships to achieve TEST-A.app1 links to TEST-B.app2 rather than TEST-A.app1 links to B.app2 which happened automatically during the initial clone event.
If someone else has a better approach for this scenario I’d love to hear it
Hmmm. The reason I placed apps in four different workspaces is just for clarity for the users. They now see the workspaces Data, Reports, Logging and Dropdown Values (their term for reference tables).
I think the best way for cloning seems to me:
Move all production apps temporarily to the Data workspace.
Do the cloning of the 4 workspaces one by one.
Move the production apps back to their original workspace
When I do this in the evening, no user will be bothered by this.
boom, that’s a great approach. Simple and effective.
I forgot how easy tape makes it to move apps between workspaces, but they maintain the same relationship links between apps when they move.
So grouping them for the cloning step, and then moving them to separate workspaces afterwards is certainly a good call there.