Custom Metadata - A better way to manage Skuid page/pageassignment/etc. migrations?

As discussed in the community in the past, managing migrations of Skuid pages/pageassignments/etc. can be difficult.  Additionally, tracking pages in a VCS is challenging and often times, what I’ve heard is that a lot of users building Skuid based pages/apps have a dedicated sandbox org that always contains the “truth” (aka. latest version).

With the introduction of Custom Metadata in Summer '15 and enhancements coming in Winter '16 (native ui support, enhanced permission management, etc.), my thinking is that this might be a great solution to overcoming some of these challenges.

I’m curious if leveraging Custom Metadata would be a fit for pages, page assignments, etc., if this has been explored/evaluated yet and if so, what the future might hold?


We would love to move to Custom Metadata for Pages, Page Assignments, Model Services, Model Service Adapters and other things. It’s probably something we’ll be exploring in the next Major Release after Banzai. The biggest issue right now is their lack of support for any long text. So we won’t be able to move Pages until something like that is supported.

There are 3 major reasons why we cannot use Custom Metadata types yet for Skuid, much as we would like to:

  1. No Long Textarea (LOB) fields — Skuid Page XML metadata is stored in a combination of several Long Textarea fields on the Page object. Because Custom Metadata types do not offer Long Textarea fields, we really can’t use them right now as a viable alternative for storing Skuid Page metadata.
  2. No Relationship / Lookup fields — the Skuid Page Version and Page Assignment objects have lookups / master-detail relationship fields to Page records. And with Banzai, the Page object has a Lookup field to Page, to allow for Master Page functionality. Custom Metadata Types do not have a concept of Relationship fields. 
  3. No Triggers on Custom Metadata types — the Page and Page Version objects have trigger logic that is essential for their functionality. Custom Metadata types do not support triggers.
  4. No DML support on Custom Metadata Types — currently we use DML to create/modify/delete Skuid objects / custom settings. Custom Metadata Types can only be edited with the Metadata API. This presents substantial migration challenges for our existing codebase, including creation / updates of records from our Post-Install Apex script, modification of pages from the Skuid UI / Composer… it would take a lot of complex migration work.

In short, we are functionally unable to migrate any of the core Skuid objects to Custom Metadata types in the foreseeable future. Some of the new configuration objects we have added with Banzai could be migrated to Custom Metadata types, but we do not have immediate plans to do this.

I have heard that Relationship fields are up soon on the Custom Metadata Types roadmap, and after that LOB fields, but no timelines have been disclosed yet.

Thanks for the insight Ben/Zach, makes sense why moving there now isn’t possible but glad to hear that it’s a potential future direction once MDT matures.  Having this in place would make things so much easier in terms of deployment management, version control, etc.

I’ve read the roadmap includes Relationship/Lookup Fields and APEX DML support, hopefully LOB & Trigger support will be included as well.  Though not ideal, I could see ways to overcome the lack of trigger support but lacking LOB would be make things difficult, or at the very least, extremely messy.

So I’ve been setting up Source Control in BitBucket. One thing that would make this setup much better would be if Skuid were to use Custom Metadata.

I’ve looked at the list of the 4 issues provided and it seems all but “No Triggers on Custom Metadata types” is now available. Is there any update on this? A workaround maybe?

I know that static resources can be used to commit changes to source control, but the issue with this is that there is still a very manual process to ensure there are no overwrites. Can’t very well pack everything into one static resource, so steps must be taken to pack changed pages into their own static resource.

Any tips and tricks anyone would recommend on this?

My current strategy is clone the Skuid Page into new Record/Named version and update Visualforce. Allows for one page pack everytime.

Pat, any reason why you’re not using Skuid Grunt or Skuid CLI ( to do source control on Skuid Pages? This is our recommended approach. When doing active development on Skuid Pages, I would definitely use one of these two tools instead of Page Packs.

Looking to avoid using any command line as it’s far from user friendly when client declarative developers get involved.

Additionally, it’s not doing a commit to a branch so a pull request would not see the differences. Code cloberring will occur using only this CLI.

Hmmm … I suppose one could stage and commit the skuid pages to the branch and subsequently use Source Control this way. Not ideal as most declarative devs are not going to easily take this on, which is to say most Skuid devs are not going to.

This doesn’t fit the whole Skuid mantra of clicks not code (CLI) though.

Any suggestions on how best to manage Skuid within Source Control with clicks not code?

We’re using Jira, BitBucket and Gearset to manage Agile Dev, Source Control and Release Management. We can click to create branches, commit changes, pull request, merge and deploy all from the cloud. Only wrinkle is Skuid Pages as they don’t transfer via metadata without Static Resources and this would additional steps in order to commit to branch and deploy to Salesforce. ie. pack and unpack.

If we had custom metadata, then everything would be a single step for each operation in the SDLC.


It’s been an uphill battle, but we’re doing everything on the command line now using bitbucket with skuid-grunt and grunt-ant-sfdc.

A clicks-only approach would definitely make it easier for new hires to get working quickly.

How about mirroring (auto saving) each Skuid page, page assignment and custom theme as a Static Resource? That way none of this malarkey about command line needs to be done.

Seems too simple to me, but can this be done?

More and more tools allow for simplified SDLC processes. We’re using Gearset and BitBucket, so we can do everything from the cloud. ie. no local repository or command line.

Hey Pat -

I’m with Zach in that cli tools are the best technical solution available currently.  Hopefully Custom Metadata based Skuid is in the future :slight_smile:

That said, you asked for a way to avoid using cli.  So while it wouldn’t be recommended, here’s a couple of thoughts.  I haven’t completely flushed these out in my head but I think they could be made to work:

1) Build a GUI based tool on top of the CLI tools.  This avoids your users having to use the CLI but functionally still uses it.  You could write the tool in any language you choose (Java, c#, etc.) and make it portable for different operating systems.  This would accomplish your goal of “clicks” for the users that are maintaining pages.  They would just need to remember go “click” in the GUI after they are done making changes.

2) Using a trigger/flow/process builder or some other SFDC feature, when a record changes, use an HTTP callout to commit that change to your VCS.  If I’m remembering correctly, bitbucket supports a REST API for various actions that can be taken.  You can leverage that such that when someone “saves a page”, it invokes a back-end process to commit that change to your VCS.  You could get really fancy here and use something like Mulesoft or Jitterbit (or some other ESB type product) that have orchestration capabilities to do more than just “commit” something.

3) Similar to #2, build a “sync” tool that takes data from Pages object and sync to your VCS.  You would build a queu’ing mechanism that would put a message in the queue indicating that someone saved a page, which org the save was in, what the record id of the save was, etc.  Then, your sync tool would poll for messages, grab the correct version of the page and sync to your VCS.

4) You could write a browser extension that the user could interact with.  The extension would “save” the skuid page and make callouts to the VCS, etc.

Again, just thinking out loud but hopefully this gives you some direction to potentially find a solution to avoid using CLI.  One thing to keep in mind with all the above is that some of them are better than others with regards to making the “save & commit to VCS” atomic - meaning that you are guaranteed to get your commit whenever someone saves.

Tthought of 1 more…

5) You could submit a feature request to Skuid to add extensibility to the Page Builder so that you can put your own “Save” button on it which would save the page and do the callout :slight_smile:

Thoughts on creating a Skuid page trigger to save the page to a static resource? This way it can be managed the same way as all other metadata in our SDLC processes. Of which no local repository or CLI is needed.

And what’s the downside of not using CLI?

I suppose that if all you’re doing with VCS is record keeping, then the trigger for creating a static resource would be fine. But you’re not going to be able to make changes to the resource and send it back to skuid that way (you could send them back to the resource in salesforce, but it wouldn’t impact the skuid page at all).

It would be easy enough to add code for the Skuid page builder to check for an update on open. I’d simply like a simplified approach for the strictly declarative devs. Which, again, is most Skuid devs.

Sounds exciting… but you want to actually change the page without opening the builder, right? It’s almost like you’re asking skuid to use your generated static resource as the page xml instead of the Page Layout text fields?

Also, Gearset look awesome!

I Am Jesus and I want a raise

Hmmmm … that would pretty slick, but I’m not sure it would be enough as there are other settings stored in other fields for the page.

Gearset is awesome for sure. Great fit for Skuid devs as it enables a declarative solution for source control solely based in the cloud. No CLI or local repos. Compare and deploy between Salesforce org, Local Repo and Source Control.