Salesforce DX Post-TrailheaDX

Now that Salesforce DX is in beta and sessions for the 2nd TrailheaDX have ended, there is a lot to get excited about!

First off, most of the sessions from the conference have been uploaded to the SF developer channel on YouTube. I added my playlist of the SF DX videos up top and the rest of their sessions below. TrailheaDX had a ton of sessions, so I’m sure you’ll find a few that are relevant to whatever Salesforce project you are working on.

With DX in beta, the arrival of a brand new trail has been created specifically for DX. Like with all trailheads, this seems to be a very well made trail that gets you through all the basics. The DX modules include an introduction, developing apps, continuous integration, and Git/Github. One thing I’ve noticed with DX intro videos and guides is that they are very CLI based. I see very little use with the new Force.com 2.0 IDE. Personally, I enjoy using IDEs, in general, more than CLIs. An IDE seems more intuitive—if built well. Plus, this will be important for my team, who are mostly admins that will be using the IDE for declarative development and then integrating their changes. Does anyone else have a strong preference using a CLI or an IDE, assuming both have the same capability?

I’m looking forward to actually testing out DX on a new Org I’m helping set up. With the combination of Git, our custom deployment tool (which uses the Force.com migration Ant tool), and Salesforce DX, I’m hoping this will cut hours from our development/deployment process and be easily adoptable by our team.

My Hopes for Salesforce DX

I work in a large IT shop with a large development team outside of Salesforce. We build and support many applications supporting various business units and internal resource groups. We use a release management tool that consumes code from a TFS server, builds said code, and then deploys that app to various environments. As most of our applications live within the local network, this process is fairly streamlined. Managing Salesforce metadata within our repository and deploying to our sandbox and production environments custom tools has been a royal pain. My hope is for Salesforce DX to vastly improve the release process to align with the rest of the dev teams.

Scratch Orgs – With our growing Salesforce team of admins and developers, making changes within an org has been increasingly more challenging. With scratch orgs, we can collaborate better in conjunction with Git merging/pushing/pulling. Another big plus is having the ability to use test data for some of our more complicated apps. Full sandboxes are extremely expensive and partial sandboxes only work if you have minimal data per object.

Git – The ability to push, pull, and merge metadata will be so great. Currently our team works in their own sandbox to make changes. Whether those changes are declarative or code-based, most of the time we have to copy/paste or recreate in our integration sandbox. From that sandbox we Eclipse to pull all of the metadata to the hard drive and then check those files in to TFS; a very arduous and error prone process. Ideally, I would like to utilize the Git functionality on our TFS servers to replace our current process with TFS.

I was able to get an invitation for the Salesforce DX pilot. With the end of June and pilot ending soon, I wasn’t able to test out all the features besides the basic needs for our team. Extended project timelines at work have not allowed me the free time I wanted to test. Although, the little testing I was able to do reaffirmed my initial excitement of DX. I’ve been excited for DX ever since it was hinted at last year.

Last year when our team was looking for solutions, we could have gone with cloud-based solutions like Flosum or Autorabit, which are designed to solve release management problems. After trying out both options, they did meet our basic requirements but were very clunky feeling and lacked the streamlined release processes of our other development teams. Naturally, I was hesitant about our team adopting one of these products that have decent price tags on them.

When hints about an improved development and continuous integration tool came from the mighty Salesforce itself, I encouraged our team to wait until Dreamforce to see what all the fuss was about. Sure enough, the developer keynote and sessions gave way to a new opportunity. Suddenly the possibility of keeping our metadata within our systems and plugging in DX was very exciting.

The pilot was a great preview of what to expect. The CLI handled everything we needed for metadata integration, but I was more excited about the DX IDE. Most of our team are declarative admins so point and click features with an IDE are definitely preferred. However, many of the awesome features of DX remained within the CLI, and I would hope they integrate more commands in the future to allow teams to merge, pull, push, etc., without having to pull up a separate tool. It seems the Salesforce dev team primarily has other developers in mind, which is great for me, but I am glad that this will encompass declarative features as well.

Speaking of the IDE, I hope it becomes a decent developer tool for apex, visualforce, and lightning. I have never been thrilled with developing in Eclipse or the developer console, so I hope they improve that experience. Being able to navigate through code and debug that code is very important to me. Perhaps mimicking some of the features the Welkin Suite has been doing would be fantastic. The Welkin Suite is great because it allows you to debug your code without having to keep a connection with Salesforce servers. It also allows you to use a lot of tools Visual Studio has, so traversing code from function to function between classes is a breeze. I was born a Visual Studio coder so I am definitely biased.

With the beta coming out for Salesforce DX, I hope to see more changes. I know my use case is very narrow when it comes to DX and Git functionality but I’d like to hear from others who are in the same boat. What other features would you like to see emphasized with DX?

Salesforce World Tour Lands in Chicago

The Chicago World Tour was much larger than I expected, which is good because I won’t be able to attend TrailheaDX or Dreamforce. There was also lots of swag that I managed to snag through vendors or Salesforce activities. The event was a good rundown of what is currently happening in the world of Salesforce.

This was my first time attending a World Tour event. First arriving at McCormick Place and noticing all the staff just directing people through this massive structure, I knew this event would be an impressive one. Walking into the main show room, everything was decorated in their typically themed forest environment. The atmosphere was vibrant with all the colors, costumed characters, food trays with food cups, and very chatty sales reps scanning your badges.

20170615_113541

The big event of the day was the keynote, which felt like one giant sales pitch the whole way through. Nothing new was showcased. Salesforce was patting themselves on the back a good chunk of the time. They even brought in their customers to have them pat Salesforce’s back as well. For me, the best aspect of the keynote was their dedication to keeping the platform innovative and continuously providing more value. That value being new tools for me to use to create a better product as a developer.

20170615_100102

The keynote was also pleasantly notable in that all the speakers were women. These are leaders within Salesforce. I really appreciated that, and am glad they didn’t highlight that fact either. It’s always important for the tech industry to highlight women in leadership without tokenizing them.

A lot of the topics that relate to me (development and Salesforce DX) were just broadly covered in the event. I didn’t learn a whole lot from these sessions that I haven’t previously researched while at work.

20170615_143659

The 50 or so vendors there actually provided me with the most value. Not only did I get free swag, I got to learn about potential opportunities that could benefit the orgs I work on. However, I’m not a fan of the sales reps’ endless emails and phone calls I get after these events.

I would suggest that others go to a World Tour event if they don’t have much opportunity to keep up to date with Salesforce in their free time. Also, the event is free, so any complaints I’ve made above are minor.

I would like to see events like Dreamforce get out of San Francisco and take place elsewhere, like World Tour does. The city is far and very expensive to stay in. I’m sure a lot of technical Salesforce folks would love to attend, which would provide a ton of value to the eventgoers if it were more accessible.

Salesforce Name Fields Can’t be Unique

Not having the ability to make unique name fields for objects is an issue if you really want them to be unique. Obviously. This seemed really odd to me since every other field you can enforce uniqueness.

This issue came up for me recently on the Salesforce project that I am working on. I couldn’t easily find a way to prevent duplicates for our new custom object. We ended up creating a custom field with uniqueness enforced and then converted Name into an auto number field. New records for this object are only going to be updated by one user a few times a year (maybe), so we didn’t worry about neglecting the benefits of the Name field.

A few days later our Salesforce platform lead came back after a break and basically said WTF guys? Oh hey, there is a way by using a VLookups within a validation rule!

Id <> VLOOKUP($ObjectType.Adam_Custom_Object__c.Fields.Id, $ObjectType.Adam_Custom_Object__c.Fields.Name, Name)

This will compare the Name field that a user wants to insert with all other name fields in your custom object and return an Id records that match. If the name already exists, the matched record will have an Id. Since the matched Id won’t match the Id of the record being inserted (Id is empty at this point), the above formula will return true and will trigger an error.

If you feel like the Name field should have a unique attribute that can be set, check out this link to upvote for the idea. Also please leave a comment here if you agree or not. Since this is my second blog post, any feedback would be great!

Why, oh why?

I never thought I would create a professional blog before. Coming out of college, I never thought sharing my thoughts and ideas would be useful or meaningful for a public audience. A lot of questions that I had about coding could be answered by my co-workers, other blogs, or sites like Stack Exchange. Oh, glorious Stack Exchange! Coming into the coding world I started out with .NET development. This framework was very well established by the time I started my first job in 2013. So creating a blog about my early experiences in a saturated environment seemed like a waste of time.

I would consider my career in software development separate from my personal life. I love solving complex problems with new and well established technology but that passion seems to stop when I am at home. Personal coding projects at home felt like a chore and a continuation of my job. Unfortunately, this prevents me from learning new technology outside of work.

What changed? Why, oh why I am creating a blog now? Two reasons. The first being that I switched jobs and ended up working for a company that I feel really cares about the career development of its employees. Many of my co-workers put effort in advancing their careers and that was very encouraging for me. Some publicly speak about a topic they learned and present to a large conference audience. Taking command of a subject and teaching others is a great way to advance your career.

I deeply and truly loathe speaking publicly. Speaking to a small group or a group of people I mostly know is perfectly fine, but a large unknown audience is not my cup of tea. I figure blogging my thoughts and ideas would be a much better medium. This allows my introverted self time to think about what to write in these things.

The second reason I am creating a blog is because I have switched from the .NET world to primarily developing for the Salesforce platform. Salesforce development will be a primary driver for a lot of my future blog posts. Before last year I had only heard of Salesforce by name and figured it was only used by sales teams. Hearing that I would be a developer for Salesforce projects, I was hesitant to believe it would be an enriching experience. To add to that hesitancy, I quickly found out that one of their slogans and mascots was “No Software”.

salesforce-dreamforce-no-software-crm_large

I had no idea Salesforce had its own programming languages, and figured they would be limited languages. Through the months of learning the platform I quickly discovered that they are limited compared to the languages they mimic. Some of these were intentional limits to counter issues that come with multi-tenant servers. Other limits are unintentional (debatable I’m sure), like not being able to use joins for a SOQL statement or within apex code, for example. The amount of apex maps I have created to relate data together is astoundingly excessive.

Navigating development in Salesforce, I found myself going through blogs, forums, and Stack Exchange again. This time around, I found there is a much smaller community of Salesforce developers out there to cover the topics I sought answers for. I’ve also found that Salesforce has made the developing experience a lower priority. I understand declarative development for the Lightning experience is more important, but as a developer you notice this very quickly. To be fair though, Salesforce has been changing their tune lately with Salesforce DX and is something I hope to write about in future blog posts.

This blog may not be the best source for new ideas or solving complex problems. Rather, it will be an outlet for me to engage with the public so I can flesh out my own ideas and relay information that has been important for me and my work. And maybe some of the struggles I talk about can be discussed and provide some value to others.