Skip to main content

For development and testing, I like to clone the existing company design system and assign it to test or cloned pages. When I am finished with the tests and clones, I delete them.


Rinse and repeat. But the next time the clone is tried with the design system, the clone name is “already in use.” Well, it isn’t because the Design System Studio does not see it. However, Salesforce still has it a static resource.


Who should be deleting the static resource? The developer, when it is no longer needed (even for backup)? Or skuid, when the developer confirms the Delete request?


I would argue that skuid should delete the static resource, or at least make reference to it in the delete dialogue, or even in the documentation.

Here is the argument we’ve had. Unlike all other forms of salesforce records - Static resources do not go to the recycle bin when deleted. Deletion is INSTANTANEOUS. We didn’t like the possibility of exposing the builder to a lot of trauma - if they expected Design Systems to work like other SFDC records - and be recoverable for a period of time when accidentally deleted. So we decided to keep the Static Resource and put the onus on the builder to “REALLY DELETE” the file.


We could be better about messaging and documentation. We’ll take that under advisement.


Reply