Because custom metadata and Flow don't mix, I had to create a service that would run the custom metadata lookup in Apex, where I can control the bulkification. Code Here is some code that will achieve this. It takes a list of field names and a list of values, and a table name, and returns the value from the lookup. To install the code, open Developer Console, and create four files: FlowLookupFlowLookupRequestFlowLookupResultMyExceptionYou can copy/paste the code from Github into those files, then save them. That will make the plugin available to your Flow. Step-By-Step Usage Here's an example that looks up a value called a "fireball" from a custom metadata table and assigns the value to a record called iLead__c.
Request and Response Formats The process has a request and a response. The request contains: Query Fields - a list of the fields you want to queryQuery Values - another list of the values for the above fieldsResult Field - the field to pull the result fromTable Name …
Recently we had a big Knowledge Centric Support (KCS) initiative where we generated a ton of Articles for use in a Community. (We're still on Classic Knowledge.)
Problem is, some users forgot to tick the "Customer" box when creating the Articles. So those articles didn't appear to external users in the Community.
You can update these Articles in bulk, but you need to use a few obscure hooks in Apex. This method will create a draft of the Article, update the Knowledge Article Version, and then re-publish without creating a new Version.
The following code will update the 'IsVisibleInCsp' flag for a single Article specified in the 1st query, which will make it visible to Customers.
Here's a bulkified version. This is heavy on the CPU so I run it 10 at a time.
When going over these in bulk, you might run into a situation where there is an existing draft of an article that has been previously published; i.e., it's actively being updated. In this example, …
Yeah, yeah, yeah, just take me to the code.
I recently had the opportunity to start writing some code in a brand
new org, which got me thinking about the best way to do test object
creation. You know, that annoying problem where you need to generate an
Account in a test class about 77 times. Here’s a pattern I came up with.
This method involves some overhead but it has the advantages of (1)
allowing you to set defaults for certain objects so you don’t have to
worry about them – for some objects create them with all defaults with
just one line, and (2) a generic, repeatable pattern.
It’s based on an abstract class that implements the base operations using some generic sObject magic outlined here.
A lot of code in this post, bear with me.
(That's a basic version, for something more robust, look here.)
For each object you will use, you need to create a class that implements the abstract factory class.
Then, in your test code you would need to instantiate the factory for eac…