From BBC Basic to Force.com and beyond…

Category Archives: Metadata API

When you have more complex custom metadata needs or multiple custom metadata types, the UI requirements for users to manage records may also need to be more sophisticated. For example if you wish to build a setup wizard or type of visual editor. Much like you see with the Flow or Process Builder tools. So if you find you want to build your own UI for custom metadata records what is involved?

The native Apex Metadata API allows for Layoutmetadata as well as Custom Metadata records to be manipulated directly in Apex, without the traditional need for callouts or elevated permissions. Due to its generic API design, the data types for custom metadata records are represented as generic name/value pairs. Because of this it does require a bit more coding than you might expect to update records. Certainly compared to the SObject and DML oriented experience you get when working with Custom Object records in Apex. There is also the fact that it is async only, requiring careful transfer of results received via callbacks back to the user.

Custom Metadata Services (CMS) is a small library created to wrap the native Apex Metadata API to leverage the native SObject types for custom metadata in a more DML orientated way. It also aims to simplify the handling of the async results when developing clients in Lightning, inspired in this case by Lightning Data Services.

Updating records in Apex

When you create a Custom Metadata Type under the Setup menu, the platform automatically generates a corresponding SObject type you can use within Apex. This so that you can query those records using regular SOQL.

Using the native SObjectType and the related field references (SObjectField tokens) is preferable to using String literals from a referential integrity perspective and also namespace management for packaged code. So CMS uses these whenever possible. The following code will upserta Custom Metadata record.

The only operation currently supported is an upsert. The use of this terminology reflects the fact that the native Metadata API deploys a list of records that will either insert or update records.

Because its not possible to assign values directly to __mdt SObject fields, the above code uses an Apex map that references the fields via their SObjectField tokens.

The native Apex Metadata API uses a background job to update the records so the results are not know immediately to the calling code. CMS tailors the DeployCallback interface with its own base class which is more orientated around custom metadata record results. CMS also uses its own callback ID rather than the native one, allowing the client to more easily identify the corresponding callback.

The callback method also supports the ability to send a Platform Event instead. This is preferable in cases where you are building UI’s, since the UI can listen for the callback directly. The Metadata Deployment platform event object is included in the library.

Here is a simple UI built with CMS, to demonstrate loading, saving and error handling.

When building UIs you can utilise the Apex code above from your server side controller logic. Though as an alternative, CMS includes a Lightning component for use within client side controllers. The design of this component follows that of the force:recordData component used for managing Custom Object records. It is currently aimed at single record retrieval and updates. Here is the markup for the above component.

The metadataRecordData component has its own Apex controller leveraging the CMS Apex API above and then listens for the MetadataDeployment__e event (included). This is transparent to the consumers of the component. The controller code interacts with the saveRecord method and metadataRecordDataResult event.

I plan on utilising CMS to update the rollup tools UI in the future and avoid the need for callouts (and related permissions) when using its UI. In full disclosure I would also classify the library as alpha at this stage, its still needs a little more refinement and robustness adding. It is open source, so free to join me in fleshing it out further!

Share this:

Like this:

As a self confessed API junkie,each time the new Salesforce platform release notes land. I tend to head straight to anything API related, such as sections on REST API, Metadata, Tooling, Streaming, Apex etc etc. This time Spring’17 release seems more packed than ever with API potential for building apps on platform, off platform and combinations of the two! So i thought i would write a short blog highlight what i found and my thoughts on the following…

New or updated API’s in Spring’17…

Lightning API (Developer Preview)

External Services (Beta)

Einstein Predictive Vision Service (Selected Customers Pilot)

Apex Stub API (GA)

SObject.getPopulatedFieldsAsMap API (GA)

Reports and Dashboard REST API Enhancements (GA)

Composite Resource and SObject Tree REST APIs (GA)

Enterprise Messaging Platform Java API (GA)

Bulk API v2.0 (Pilot)

Tooling API (GA)

Metadata API (GA)

Lightning API (Developer Preview)

This REST API seems to be UI helper API that wraps a number of smaller already existing REST API’s on the platform. Providing a one stop shop (a single API call) for reading both record dataandrelated record metadata such as layout and theme information. In addition to that it will resolve security before returning the response. If your building your own replacement UI or integrating the platform into a custom UI. This API looks like it could be quite a saving on development costs, compared to the many API calls and client logic that would be required to figure all this out. Reading between the lines its likely its the byproduct of a previously internal API Salesforce themselves have been using for Salesforce1 Mobile already? But thats just a guess on my behalf! The good news if so, is that its likely pretty well battle tested from a stability and use case perspective. The API has its own dedicated Developer Guide if want to read more.

External Services (Beta)

If there is one major fly in the ointment of the #clicksnotcode story so far, it’s been calling API’s. By definition they require a developer to write code to use them, right? Well not anymore! A new feature of delivered via Flow (and likely Process Builder) allows the user to effectively teach Flow about REST API’s via JSON Hyper-Schema (an emerging and very interesting independent specification for describing API’s). Once the user points the new External Services Wizard to an API supporting JSON Hyper Schema it uses the information to generate Apex code for an Invocable Method that makes the HTTP callout. Generating Apex code, is a relatively new approach by Salesforce to a tricky requirement to bring more power to non-developers and one i am also a fan of. It is something they have done before for Transaction Security Policies plugins and of course Force.com Sites. At time of writing i could not find it in my pre-release org, but i am keen to dig in deeper! Read more here.

SObject.getPopulatedFieldsAsMap API (GA)

So calling this an “API” is a bit of stretch i know. Since its basically a existing Apex method on the SObject class. The big news though is that a gap in its behaviour has been fixed / filled that makes it more useful. Basically prior to Spring this method would not recognise fields set by code after a record (SObject) was queried. Thus if for example your attempting to implement a generic FLS checking solution using the response from this method, you where left feeling a little disappointed. Thankfully the method now returns all populated fields, regardless if they are populated via the query or later set by code.

Reports and Dashboard REST API Enhancements (GA)

Its now possible to create and delete reports using the Analytics REST API (no mention of the Apex API equivalent and i suspect this wont be supported). Reports are a great way to provide a means for driving data selection for processes you develop. The Analytics API is available in REST and Apex contexts. As well as driving reports from your code, Report Notifications allow users to schedule reports and have actions performed if certain criteria is met. I recently covered the ability to invoke an Apex class and Flow in response to Report Notification in this blog, Supercharing Salesforce Report Subscriptions. In Spring, the Reports REST API can now create notifications.

Composite Resource and SObject Tree REST APIs (GA)

An often overlooked implication of using multiple REST API calls in response to a user action is that if those calls update the database, there is no over arching database transaction. Meaning if the user was to close the page before processing was done, or kill the mobile app or your client code just crashed. It is possible to leave the records in an an invalid state. This is bad for database integrity. Apart from this, making multiple consecutive REST API calls can eat into an orgs 24hr rolling quota.

To address these use cases Salesforce have now released in GA form the composite and tree APIs (which actually this was already GA, how did i miss that?!). The composite resource API does allow you to package multiple CRUD REST API calls into one call and optionally control transaction scope via the AllOrNothing header. Allowing the possibility of committing multiple records in one CRUD API requested. The tree API allows you to create an account with a related set of contacts (for example) in one transaction wrapped REST API call. Basically the REST API is now bulkified! You can read more in the release notes here and in the REST API developers guide here and here.

Bulk API v2.0 (Pilot)

Salesforce is overhauling their long standing Bulk REST API. Chances are you have not used it much, as its mostly geared towards data loading tools and integration frameworks (its simply invoked by ticking a box in the Salesforce Data Loader). The first phase of v2.0 changes to this API allow it to support larger CSV files to be uploaded and automatically chunked by the platform without the developer having to split them. Also changing the way limits are imposed, making it more record centric. Read more here.

Tooling API (GA)

Tooling API appears to be taken on new REST API resources that expose more standard aspects of the platform, such as formula functions and operators. For those building alternative UI’s over these features its a welcome alternative to hard coding these lists and having to remember to check / update them each release. Read more here.

Metadata API (GA)

Ironically my favourite API, the Metadata API has undergone mainly typical changes relating to new features elsewhere in the release. So no new methods or general features. I guess given all the great stuff above, i can not feel to sad! Especially with the announcement recently from the Apex PM that the native Apex Metadata API is finally under development, of course safe harbour and no statement yet on dates… but progress!

Salesforce continues to add to the ever expanding places in which developers can extend Lightning Experience using standard or custom Lightning Components. In a recent blog i covered Lighting Component Actions. This blog focuses on the Utility Bar. While also showcasing the Base Lightning Components also new for Winter’17.

If enabled, this displays a rectangular region shown in the footer region of Lightning Experience (it does not apply to Salesforce1 mobile currently). Regardless of where the user navigates, it remains present and its contents always visible. Its display and content is dependent on the currently selected application (just like tabs are in classic). If your from a Windows background it will likely remind you of the status bar!

Salesforce have utilised this for their new Lightning Voice functionality. Providing you have the required license for it, you can enable it under the new Application Manager. There just one hitch. For now there is no general Setup UI to configure your own utility bar or for that matter, add components to it, at least not until Spring’17 anyway.

However worry not! There is Metadata API support available now (in pre-release orgs only as i write this blog). This is all we need to unlock the power of the utility bar! Which means it can also be packaged (as part of your CustomApplication metadata) and accessed via the Migration Toolkit. Eventually also within IDE’s once they catchup with API v38. I am told however that Tooling API support is planned for Spring’17.

Sample Utility Bar Application

If you cannot wait to go try out the utility bar at this point, click the Deploy to Salesforce button below and it will deploy a sample application (make sure to use a Winter’17 org). Once deployed go to the App Manager under Setup and assign the Utility Bar Demo application to your profile.

Alternatively if you want to clone the repository and have Ant installed. You can edit the sample FlexiPage included and use the ant deploy command deploy your changes. Be sure to enter your org login details into the build.properites file. If you have managed to contain your excitement and want to know more, read on…

Updates to the FlexiPage Metadata Type

The utility bar content is driven by a Lightning Page or better known behind the scenes as a FlexiPage. FlexiPage’s have different types (see the type field in the docs). A page of type UtilityBar cannot be created with Lighting App Builder. So it must be expressed in its Metadata API form. This is what such as FlexiPage looks like…

This is pretty much what a standard FlexiPage looks like with a couple of differences. First the type is set to UtilityBar. Second component attribute values now support a new decoratortype. This means that the attribute value is used to configure a dynamically created UI around (wrapped) your component when the user opens it from the utility bar. Rather than being passed to the component itself.

You can mix the two attribute types, those passed to your component vs those used by the wrapper. The formal list of decarotor attributes for utility bar components has not yet been documented, those above can also be seen in the Voice Utility FlexiPage. I’ll be sure to update this blog when they are. Meanwhile this is what the API docs have to say…

If this field value is decorator, then the ComponentInstanceProperty values apply to the component decorator for the Lightning component. The component decorator is a wrapper around a Lightning component. The decorator can apply additional capabilities to the component when it renders on a specific page in Lightning Experience. For example, you can configure a component decorator around a component on the Lightning Experience utility bar to set the component’s height or width when opened. The UtilityBar is the only page type that supports component decorators.

Updates to the CustomApplication Metadata Type

Once you have defined your FlexiPage you need to reference it from your CustomApplication metadata. This is as simple as specifying it via the new <utilityBar> element (see docs). There are also quite a number of new elements for branding etc.

The above example uses some simple custom Lightning Components included in the accompanying repo for this blog. The only requirement for a component to appear on the utility bar is it has to implement the flexipage:availableForAllPageTypes interface. The follow shows the new Winter’17 lightning:tabset base component.

The components included in this demo showcase the Base Lightning Components examples from the current documentation. I have no doubt the community will be digging into these very soon. So far they look very solid and quite feature rich.

Summary

I am eager to see how this feature rolls out further, as there is so much potential for this feature in reducing navigation overheads and thus improving user productivity. I’ll certainly be exploring a bit further with this sample to see what events and interactions are possible, which i’ll surely follow up on in a future blog.

When i first heard about this feature in Winter’17 preview webinar i was very excited to try it out and not having a UI was of course not going to hold me back! Thanks to Eric Jacobson for helping with early pointers that helped me pull this together.

I think its a great move for Salesforce to deal with the juggling priorities vs development resources by deploying new features via API only if needed and as i have said before a true testament to their commitment to their API first strategy.

IMPORTANT NOTE:
As per the usual Salesforce Release Notes documentation warning. Until Winter’17 goes out to production, information in this blog and associated information should be considered subject to change. I will continue to monitor for updates in the documentation and update accordingly.

Share this:

Like this:

During last years fun with IoT and the LittleBits devices, i developed a package imaginatively called Salesforce LittleBits Connector. My aim for that connector was to allow none coders, to have some fun with IoT and Salesforce. Instead of requiring Apex code to control devices and respond to events i wanted to allow the user to leverage Flows. When building it a previously observed limitation with the Apex integration with Flow surfaced again…

Whats the problem?

While Apex can create a Flow that is known at the time code is written, it cannot dynamically create a Flow determined at runtime. My blog entry Calling Flow from Apex goes into what is currently possible and highlights this restriction towards the end. This idea proposes that Salesforce adds something like the following to Apex…

// Create the Flow named in the userDefinedFlow variable
Flow.Interview.Interview anyFlow =
Flow.Interview.newInstance(userDefinedFlow, flowParams);
// Run the Flow
anyFlow.start();
// Retrieve a value from one of its variables
String outputValue =
(String) anyFlow.getVariableValue('outputVarName)';

Current solutions…

Salesforce describes the current options for launching Flow here, one of which is indeed via its REST API, which if called from Apex would provide the facility we are looking for here, however i wanted to avoid HTTP callout and the limitations that entails. With the Salesforce LittleBits Connector i solved the problem using an Apex interface, the utilisation of the factory pattern and a Tab that provides a facility to manage the code generation of a Flow factory class.

The following code snippet from the tool shows how the Flow factory approach works. It uses Apex type.forName to create an instance of the above generated class (from the unmanaged namespace of the org).

The key with this solution is the Tab above that provides a means for the Admin user to dynamically create or refresh the lbc_LittleBitsFlowFactory Apex code which has access to the specific Flows. This class lives as an unmanaged class in the org. Before we look at how the Tab works, lets take a closer look at what it generates in the org.

Note: I found that i needed the class to be marked as global at the time, i suspected this might have been that the packaged code was not Aloha status. If your not packaging your solutions code, this your code runs in the unmanaged namespace, you’ll find that you don’t need global and public will be fine. The Tab also generates an Apex Test for the above code as well, to ensure code coverage is satisfied.

The Tab itself scans the configurations of the tool for references to Flow names, in this case it was LittleBits Device Subscriptions, it could also utilise the Apex Metadata API listMetadata as well. The former approach does keep the generated code focused on the Flows needed by the tool. The page then uses the Apex Metadata API to deploy the generated code to the org. If you want to review this code in more detail take a look at ManageFlowFactoryController and the manageflowfactory page.

Summary

I find Flow to be a hugely liberating technology for creating solutions without requiring coding skills on Salesforce. I hope to wrap the above solution in a standalone open source solution that contains a dynamic Flow API and the Tab above, such that others can start to integrate Flow into other tools as I did with the LittleBits connector. Meanwhile please enjoy reviewing the approach in its current form and let me know your thoughts!

Note: Key to this solution is the use of the Apex Metadata API to deploy the factory code. I have learnt recently that Salesforce are increasing security around Apex execution invoked from Lightning Components (via @AuraEnabled annotated methods). The implication of this is that UserInfo.getSessionId does not return an API capable Session Id. This effectively blocks such code from calling any Salesforce API’s (including Metadata API) via Http callouts using the users Session Id. I’ll be looking at means in the future to use oAuth to formalise access like this.

Having just completed some improvements to the Apex Metadata API to support creating, reading, updating and deleting Flows. I wanted to give it a bit more of test drive than the usual Apex examples i write. So i started wondering if there was something i could do as a developer armed with this API to help with the process of configuring and managing Flows? The following is basic example of updating a Flow to add a Screen Step….

Doing this manually is a simple matter of dragging a Screen Flow element onto the canvas and configuring it with the type of UI fields you want to see. In scenarios where your step is surfacing fields from objects you can mirror those fields by setting up the Screen element with labels and field types based on the underlying field metadata.

However wouldn’t it be much easier if we could simply state which object fields we want and automatically use their metadata to drive the creation of the fields in the UI. Reusing the labels and selecting the applicable field type. The following code uses the Apex Metadata API with Apex Describe to show how something like this can be done.

There is certainly i’m sure a number of other possibilities for dynamically generating or indeed updating Flows, that can now be realised in Apex through the Metadata API. I’m certainly keen to know what people think of the above and any other thoughts like it…

Share this:

Like this:

As soon as I got my hands on the LittleBits kit last December, i quickly fell in love with it. With its mission to bring IoT and electronics closer to everyone or in the words of LittleBits themselves …

OUR MISSION IS TO DEMOCRATIZE HARDWARE

It felt very familiar! Salesforce’s own Clicks not Code methodology is effectively the same but for Software! However i quickly found some missing capabilities. While IFTTT (default way to control LittleBits) is great, there is only support for sending a Chatter Post. But no way to have Salesforce control devices or respond to them in different ways.

Here is very cute creation from SNUGSFBAY using an early release… “this guy’s blue light shines when Salesforce targets are met!”

Dreamforce 2015

If your attending Dreamforce, I’ll be explaining more about IoT, its background, why you need to thinking about it and how you can have some fun exploring ideas with Salesforce and LittleBits, click the link below to signup to my session!

Abstract: Devices are soon to out number humans as connected things on the internet! Are you prepared for judgement day? LittleBits is the perfect hardware complement to Salesforce’s clicks-not-code approach. No knowledge of electronics or even how to solder wires together is required. It’s all plug and play, or clicks-not-solder! There are over 40 LittleBits modules allowing projects such as automatic fish feeders, burglar alarms, or anything you can imagine. Join us to see how we’ve built the LittleBits Connector for Salesforce. Learn to connect your own Internet of Things creations to your Salesforce objects, processes, and reports using clicks-not-code via LittleBits

Latest Release of the LittleBits Connector

The latest release of the LittleBits Connector v1.12 now provides full support for integrating with LitteBits devices. Meaning you can now not only tell the device to perform an action from Salesforce, but you can also have Salesforce respond to messages (or events) the device sends. Your imagination is really the only limit! Choose from one of its many input bits, such as sound, movement and other sensors. As before this is made possible without coding at all!

Here is a sneak preview of one of my slides from my Dreamforce session above…

Simply create a Salesforce Summary Report and the connector runs the report on an hourly basis and updates your chosen device! In the following example, i created a report showing Closed Won Opportunities for the period, leveraging a formula field in the report to arrive at the all important target percentage i would then pass to my device.

You can then define a LittleBits Report Trigger to tell the connector about the Salesforce Report and some details of where information can be found in the report. The Test button can be used to run the report immediately, so you can check everything is working fine. Finally use the Schedule button on the List View to schedule the job to run hourly.

Responding to Devices with Salesforce Visual Flow

Once again inspired by Cory Cowgill‘s sample here, this declarative feature allows you to connect LittleBits sensors (moving, sound, buttons etc) and any LittleBits input bit to Salesforce. Events sent to Salesforce are handled by Salesforce Visual Flow, or more specifically a Autolaunched Flows that you create. This is a very powerful #clicksnotcode tool, meaning the possibilities are practically endless in terms of what you can do in Salesforce in response to events from your latest device!

Once you have configured your org to receive device events, you can setup a LittleBits Device Subscription to start listening to specific events from your devices and routing them to your chosen Flow. You can read more about how to configure your org and these events on the wiki here.

You will have to have some experience with Visual Flow, but don’t be scared its quite easy to use and i’ll walk you through some examples to get you started in my Dreamforce session! Plus there are many many great resources in the Salesforce Community to help you.

The following Flow has only one step, Record Create, that simply echo’s the information passed from the device to a custom object as a kind of device event log. However you can of course do anything you like in Flow with its many conditional and data elements at your disposal!

Summary

I’m really very excited to see what happens next in the community with this latest release. There have already been some exciting devices from my fellow MVP’s in the community, what will you build next?!!

Like this:

This is the final part of my two part blog series on Summer 15’s new Custom Metadata feature. The first blog focused on defining the Custom Metadata Type (MDT for short) and reading and writing record data with the resulting SObject, via a combination of SOQL and Apex Metadata API. In this blog I will walk through the reminder of my proof of concept experience in trying out the new Custom Metadata feature of Summer’15. Specifically focusing on building a custom UI (no native UI support yet), AppExchange packaging and finally trying it out with Change Sets!

Custom UI’s for Custom Metadata Types

As described in the previous blog native DML in Apex against MDT SObject’s is not supported as yet. So effectively making a HTTP SOAP API (Metadata API) call to update MDT records made the execution flow in the controller a little different than normal, my solution to that may not be the only one but was simple and elegant enough for my use case case. As this was a POC i really just wanted to focus on the mechanics not the aesthetics, or user experience, however in the end i’m quite pleased with all.

Creating Records. The user first goes to the page and they see Create new…. in the drop down and the Developer Name field is enabled, hitting Save creates the record, refreshes the page and switches to edit mode. At this stage the Developer Name field is disabled and the drop down shows the recently created record selected by default.

Editing Records. In this mode the Developer Name (Object Name) field is disabled and Delete is enabled, users can either hit Save, Delete or pick another record from the drop down to Edit.

Deleting Records. By picking an existing record from the drop down, the Delete button is enabled. Once the user clicks it the record is deleted and the page refreshes (its a POC so no second chances with confirmation prompts!), then defaults back to selecting Create new… in the drop down.

So thats a simple walkthrough of the UI done, lets look at how it was built. In keeping with my desire to leverage the fact that MDT’s result in actual SObject’s i set about using some of the standard Visualforce components, to get the labels and some field validation via components like apex:inputField initially.

Currently the platform extends the fact that the SObject record itself cannot be natively inserted, to the fields themselves, and thus they are marked in the schema as read only. Which of course apex:inputField honours and consequently displays nothing. This is a shame, as i really wanted some UI validation for free. So as you can see from the sample code below i switched to using apex:inputText, apex:inputCheckbox etc. which do in fact still help me reuse the Custom Field labels, since they are placed within an apex:pageBlockSection.

You will also see thats its a totally custom controller, no standard controller support currently yet either. Other than that its fairly basic affair to use Visualforce with MDT SObject’s once the custom controller exposes an instance of one, in my case via the LookupRollupSummary property. The full source code for the controller can be found here, lets walk through the code relating to each of its life cycles. Firstly page construction…

Note: Here the DeveloperName is used, since when redirecting after record creation I don’t yet have the ID (more a reflection of the CustomMetadataService being incomplete at this stage) so this is a good alternative. Also note the SOQL code above is not recommended for production use, you should always use SOQL arrays and handle the scenario where the record does not exist elegantly.

In the controller constructor the MDT SObject type is constructed, as the default behaviour is to create a new record. After that the init method fires (due to the action binding on the apex:page tag), this method determines if the URL carries a reference to a specific MDT record or not, and loads it via SOQL if so. You can also see in the getLookups method SOQL being used to query the existing records and thus populate the dropdown.

As the user selects items from the dropdown, the page is refreshed via the load method with a custom URL carrying the selected record and the init method basically loads it into the LookupRollupSummary property and results in its display on the page.

These methods leverage those i created on the CustomMetadataService class i introduced in my previous blog to do the bulk of the work, so in keeping with Separation of Concerns keep the controller doing what its supposed to be doing. Whats important here is that when your effectively making a HTTP outbound call to insert, update or delete the records, the the context your code is currently running in will not see the record until it has ended. Meaning you cannot simply issue a new SOQL query to refresh the drop down list controller state and have it refreshed on the page. My solution to this, and admittedly its a heavy handed one, is to return my page reference with the developerName URL parameter set and setRedirect(true) which will cause a client side redirect and thus the page initialisation to fire again in a new request which can see the insert or updated record information.

Populating MDT SObject Fields in Apex

As i mentioned above, MDT SObject fields are marked as read only, while Visualforce bindings appear to ignore this. Apex code is not immune to this, and the following code fails to save with…

Its not ideal, but does allow you to get as much re-use out of the MDT SObject type as possible until Salesforce execute more of their roadmap and open up native read/write access to this object.

Packaging Custom Metadata Types and Records!

This is a thankfully UI driven process, much as you would any other component. Simply go to your Package Definition and add your Custom Metadata Type, if it has not already been brought in already through your SObject type references in your Visualforce or Apex code. Once added is shown as a Custom Object in the package detail page.

You can also if you desire package any MDT records you have created as well, which is actually very cool! No longer do you have to write a post install Apex Script to populate your own default configurations (for example), you can just package them as you would any other peace of Metadata. For example here is a screenshot showing the packaging of a default rollup i created in the packaging org and it showing up on the Add to Package screen. Once installed this will be available to your packaged Apex code to query.

This then shows up as a Custom Metadata Record in your Packaged Components summary!

Finally note that you can have protected Custom Metadata types (much like Custom Settings), where only your packaged Apex code can read Custom Metadata records you have packaged and subscribers of your package cannot add new records, here you would want to use the aforementioned ability to package your MDT records. The Metadata API cannot access protected MDT’s that have been installed via a managed package.

Trying out Change Sets

I created myself test Enterprise Edition and Sandbox orgs, installed my POC package in both and eagerly got started trying out Change Sets with my new Custom Metadata type! Which i admit is the first time i’ve actually used Change Sets! #ISVDeveloper. The use case i wanted to experience here is simply as follows…

User defines or updates some custom configuration in Sandbox and tests it

User wants to promote that change to Production as simply as possible

In a world before Custom Metadata, platform on platform tools such as Declarative Lookup Rollup Summary, approached the above use case by either expecting the user to manually re-enter configuration, or doing a CSV export of configuration data, downloading to a desktop and re-upload in the Production org. This dance is simply a thing of the past in the world of Custom Metadata! Here is what i did to try this out for the first time!

Setup my custom metadata records via my Custom UI in the Sandbox

Created a Sandbox Change Set with my records in and uploaded it

Deployed my Change Set in the Enterprise org and job done!

Conclusion and Next Steps for Declarative Rollup Summary Tool?

I started this as means to get a better practical understanding of this great new platform feature for Summer’15 and i definitely feel i’ve got that. While its a little bitter sweet at present, due to its slightly raw barry to entry getting into it, it’s actually a pretty straight forward native experience once you get past the definition stage. Once Salesforce enable native UI for this area i’m sure it will take off even more! My only other wish is native Apex support for writing to them, but i totally understand the larger elephant in the corner on this one, being native Metadata API support (up vote idea here).

So do i feel i can migrate my Declarative Lookup Rollup Summary (DLRS) tool to Custom Metadata now? The answer is probably yes, but would i ditch the current Custom Object approach in doing so? Well no. I think its prudent to offer both ways of defining for now and perhaps offer the Custom Metadata approach as a pilot feature to users of this tool, leveraging an updated version of the pilot UI that already exists as a Custom UI. For sure i can see how by leveraging the tools use of Apex Enterprise Patterns and separation of concerns, i can start to weave dual mode support in without to much disruption. Its certainly not a single weekend job, but one that sounds fun, i’ll perhaps map out the tasks in a GitHub enhancement and see if my fellow contributors would like to join in!

Other Great Custom Metadata Resources!

In addition to my first blog in this series, here are some resources i found while doing my research, please let me know if there are others, and i’ll be happy to add them to the list!