A great thing that was added back in 2009 or so was the ability to add Recurring Tasks and Events.  Through Recurring Events and Tasks, you no longer had to add a weekly event or task one by one.  The only drawback to recurring activities is the inability to reassign them through a trigger.  If you try to do this, you will get a huge error that is about 4 lines long that, more or less, says you cannot reassign recurring activities.  The reason this usually occurs is because the person creating the trigger is aiming to reassign each instance of the Recurring Activity.  This cannot be done with a trigger from the Force.com API.  But, if you would like to reassign the entire Recurring Activity, that is a different story.

For the sake of this post, I will only write about Recurring Tasks.

When recurring tasks were added, the following fields were added behind the scenes:

At the time, eleven new fields were added to the data model for recurring tasks, all of which contain the word ‘Recurrence’ in the API name.  These fields are in the data model for all tasks and events, but cannot be viewed through the UI.  The values of these fields are not visible through a view or a custom report.  (You can view them by using the Force.com Explorer, though.)

When trying to reassign Recurring Tasks through a trigger, I focused on two fields: IsRecurrence and RecurrenceActivityId.  Hidden in the “User Guides” or the “Help and Training” pages is that, while you cannot reassign one or more instance of a recurring task, you can edit the one task that defines the activity and the schedule.  Therefore, it is possible to reassign Recurring Tasks by using a trigger.

The defining Task (which we will call DT) will have the IsRecurrence field set to true.  Each instance of the Recurring Task (which we will call RT_n, where n is each instance) will have the IsRecurrence field set to false, but the RecurrenceActivityId field will be set to the ID of the Defining Task (or, in other words, DT.Id ).  In order to differentiate between an instance of a Recurring Task and a simple one-time task, the one-time task will have the RecurrenceActivityId field null.

A quick chart to understand this:

When locating the tasks/events that you would want to reassign without an error, you want to locate the records where the IsRecurrence field is set to true OR IsRecurrence is set to false, but the RecurrenceActivityId is null.  I used this in the where clause to find these activities:

AND (  IsRecurrence =: true OR ( IsRecurrence =: false AND RecurrenceActivityId =: null))

I hope this helps in the future.

In the past week, I was assigned a task that many administrators may have been given in the past few years.  A situation arose where an Account Rep (let’s call her Rep A) was planning on being out for maternity leave for the next few months, and they needed another Account Rep (let’s call this person Rep B) to take over her accounts during that time.

I reviewed both user’s security settings to see what I could use and what I needed to change in order to get the ideal functionality to work.  The Account Reps shared Profiles, but had different Roles.  The trick here was that the Rep B will be managing the accounts of Rep A, while simultaneously managing their own accounts.  I’m mentioning this because my first inclination to complete this task was to simply change the Role of Rep B and call it a day.  That was just silly.   My first approach was to setup a Public Group with the two Roles.  But that wouldn’t work on many levels, including the fact that this shouldn’t affect the other users that have been assigned those two Roles.

The second idea I had was to use Permission Sets.  When Permission Sets were introduced a few years ago, I was extremely excited about it.  The major reason I was excited was because months before, I had to merge two separate Profiles.  I don’t know if anyone has ever merged two different Profiles before, but it goes up there with pulling the teeth of a newt: it’s so tedious, there are so many details and, when you are about 75% into the task, you really question why you are doing this inane task.  In case you are wondering, there is no simple way to merge Profiles.  (Well, there wasn’t an easy way to merge Profiles back in early 2011.). Permission Sets were a wonderful addition to salesforce.com, but they really focus on Profiles and the security aspects that profiles provide.

After thinking about this for a few minutes, I decided to draw a diagram to get  better understanding of where I am and where I want to be.  In diagram A, I have 3 different roles that are all at the same level in the role hierarchy.  If the goal is to provide a single user in Role B access to records that a user in Role A would have, without removing their current access, an intermediary has to be created.  This is displayed in diagram B, where I created a temporary role that doesn’t remove the access rights of Role B, but does provide the access rights of Role A.

 Diagram A:

 Diagram B:

There is a small caveat in that the user that is in this temporary role will have hierarchy access over the users still in Roles A and B, but it will only be temporary.  Also, this may not be the best way to accomplish this task, nor is it the only way to accomplish it.  For the task that I needed to solve, it worked well and without issues.

In the attempt to make the Force.com Developer Community more robust and established than it has been in the past year, I have decided to have user group meetings on a monthly basis.  That may seem like something that any user group should be doing, but there are not that many people who are looking to either host or speak at a Chicago Force.com Developer User Group meeting.  I try to avoid having vendors speak, unless they can provide a developer’s slant on their product, such as customizations or if their application is unmanaged.  There are not many vendors that cater to developers on the Force.com platform, and this is why many of the meetings are dependent on other developers presenting.  In order to have a meeting schedule with more consistency, I am ending this dependency.  Starting in June, the Chicago Force.com Developer User Group will become more community based, and there will be a general meeting when there is not a speaker scheduled.

The purpose of this meeting will be two-fold:  First, it will be a meeting where other Force.com developers from around the Chicago area can come discuss any issues or difficulties they have been having on the platform.  These difficulties can range from a specific trigger that won’t work to trying to understand the Force.com Streaming API.  Other people attending the meeting may be able to assist or other people may be having the same issue.  Either way, the benefit that is reached is that the issue gets resolved, or at least that person knows that they’re not the only one that has been having that same difficulty.  Think of these meetings as “Live Discussion Boards.”   They may also simply be “Discussions,” but you can actually find measurable value from these discussions if someone answers your question.

The second purpose is to try to reach out to people and introduce Force.com development to people who have been looking for an educational resource.  The job market for Salesforce.com Administrators and Developers in Chicago is incredibly packed with openings in the Loop and in the suburbs.  The only problem that I have heard from recruiters is that there aren’t any people available to fill the spots.  I mean, the pool of people is so small, that I believe we all know each other.

I would like to open the Chicago Force.com Developer User Group to welcome people who would like to know more about the Force.com Platform, developing on the platform and other possibilities that the platform has available.  This first meeting will be an introduction to the Force.com platform, as well as VisualForce and Apex.  If you know someone who has had questions about Salesforce.com or about being a Force.com developer, this would be the time to suggest they come to the user group meeting.

While a User Group cannot provide work experience, perhaps it will be able to give people the opportunity to feel comfortable to begin a new journey.  Maybe the reason that people don’t try to do Force.com development is because they know how Visual Studio costs $3K for .Net development, and Workday asks for $1,500 before you can get a peek at their development platform.  People may not be aware that there are numerous learning tools available to anyone, including an entire development environment, for free just by going to developer.force.com.  I want to provide people with new opportunities to join the community.

And it begins with establishing the community.

A useful tool that is widely used in Chatter is the ability to use Groups.  Chatter Groups are collections of individual chatter users that are assembled because of a certain attribute or feature that they all have in common.  The feature that makes these individuals alike can be a selling territory, a project, or something like an office committee.  There are two types of Chatter groups that can be created:

• Public: Only group members can post updates. The posts can be viewed by anyone following the group and anyone can join the group without an invite or approval.
• Private: Only the Owner, or designated Managers, of a Private Group can add members.  These members are the only ones who can post updates or view updates.

An issue that I ran into recently was how to merge two public Chatter Groups, both with over 200 members.  The only result that was required after the merge was that the members from Group B were now part of Group A.  The posts and comments from Group B would be nice to have, but the transfer of that information is not necessary.

After contemplating how to accomplish this, I quickly did a search for Chatter Group merge in the Salesforce AppExchange.  Right away, I was presented with an app called GroupMaster by Force.com Labs (created by Jonathan Hersh, more specifically.)

GroupMaster is easily installed and contains only a custom tab.  When you navigate to that tab, you are presented with a page that contains three steps.  The first step is to choose the operation that you want to be carried out with the application, and the actions that follow are dependent on that choice.

The three operations are:

Group Merge:   Through Group Merge, you have the ability to copy the posts, comments, and members from one or more Chatter Groups into one a single existing Chatter Group.  When this operation is selected, the second step allows you to pick one or more source Chatter Groups.  These are the group(s) from where you would like to pull the members, posts and comments out and place inside another existing Chatter Group.  The Chatter Group where all this information will be sent is also selected in step 2, and is designated as the Destination Group.   Before the batch job is executed, GroupMaster also provides the option to delete the Source Group(s) after the merge.  I wouldn’t recommend doing this, since you may like to confirm the merge worked correctly before deleting any source material.

Group Copy:  Group Copy allows you to copy any Chatter Group into a new Chatter Group.  With Group Copy, you can copy the group while preserving its posts, comments, and members.   When this operation is selected, you would choose a single Source Group and the name of the new group.  Group Copy gives you the option to either copy the posts, comments and members into the new Chatter Group, or just copy the members.

A key note to keep in mind is that you should use Group Copy when you want a new Chatter Group created.  The other two options require an existing Group to be available before the batch process can be executed.

Mass Add Group Members:   The last operation available in Group Master is to Mass Add Members to a Chatter Group.  Unlike the previous two operations, which provide an option to include posts and comments from a Source Group, this operation only focuses on the members of the group.  Using this operation, you can quickly add members to an existing Chatter Group by adding all the Salesforce Users who are in certain Roles, certain Profiles or are currently members of other existing Chatter Groups.  The great thing here is that it’s not an “OR” situation, in that you would have to choose Users in a Role or a Profile.  You can choose multiple Roles, Profiles and Chatter Groups to obtain the new members of the Destination Group.    There isn’t a secondary option for the Mass Add Members operation, which makes it very straight forward.  Choose which Role, Profile or Chatter Group all of the members you would like to add are currently in…and add them to the selected group.  It’s that simple.

Whether you want to merge two Chatter Groups into one, or you would like to add all of the Regional Sales Reps into a single Chatter Group, there is a simple way to manage it.  And it’s Group Master.

About a week ago, I passed the Salesforce.com Advanced Administrator certification test. This leaves the Advanced Developer certification and the Technical Architect certification remaining for Salesforce.com certifications. While I understand that people should not stop while they are on a roll, I am really looking to focus on other things, such as work for clients, helping out on the DeveloperForce discussion boards and learning new technologies, like Ruby, Rails and how to use Heroku.

I have been meaning to learn Ruby and Rails for about 2 – 3 years, but haven’t really had the time or programming awareness to learn it effectively. With all of the Salesforce.com and Windows Phone 7 work that I have been doing over the past few months, I felt like now could be the best time to approach it and apply it to productive use.

Over the past 2 – 3 years while I have been trying to learn Rails, I have accumulated many books about learning Rails, but unfortunately many of them cover Rails2. Late in 2009 or early in 2010, Rails3 was released, and regardless of what anyone else says, really made Rails 2 obsolete. The book that I have been using to learn Rails3 has been Michael Hartl’s “Ruby On Rails 3 Tutorial,” which includes sections on Ruby, on Git as well as integration of the samples into Heroku. So far, it’s been a very helpful book, with a great website, and a very educational time.

At some point towards the middle of December, I decided to go after and get both my Salesforce Service Cloud Consultant and Salesforce Sales Cloud Consultant certifications.  On Christmas Eve, I achieved the Service Cloud certification.  I hoped to get the Sales Cloud certification before the New Year began, but scheduling conflicts delayed that achievement for the second day of the New Year.

The Sales Cloud Consultant exam seems both similar and different compared to the Service Cloud exam.  The similarities are simple: both tests evaluate you on the application of the knowledge rather than the nuts and bolts, and both tests stay within the limits of their specific features.  The main difference I noticed is that while the Service Cloud exam expects you to know baseline information about Salesforce organizations, the Sales Cloud exam tests you thoroughly on these items.  As I mentioned in my Service Cloud exam post, there was a large focus on reports and KPIs in that exam.  In the Sales Cloud exam, if you do not know your security and accessibility rights and settings, there is no way that you will pass this test.  From Profiles and Roles, to Sharing Rules and Account Teams, this test covers the broad spectrum of security within Salesforce.

The rest of the test is straight forward:  Leads and Campaigns, Opportunities and Products, Forecasts and Quotas.  Another thing to understand is the differences and similarities between Partners:  Accounts versus the Portal.  Use the Partner Training if it’s available and jump in an org to get accustomed to areas that you may not be familiar with.  And by gaining that familiarity, the Sales Cloud Consultant certification exam should be well in your grasp.

This morning, I finally got around to obtaining my Service Cloud Certification from Salesforce. I’ve been meaning to get past that test since late October of this year, and then during the down time of the holiday season, I decided to get it done.

Before I provide my thoughts on the exam, a quick note: I took the exam in late October and did not do that well. During the months of November and December, I worked on a Service Cloud implementation, and it was then I realized that I truly deserved to do as badly as I did.

My thoughts on the exam are that it really is not bad as it seems if you know what each feature is, and as long as you run through the Partner Training. The Partner Training is a real lifesaver, as far as getting to know everything. Some key pointers are to know your KPIs. Good lord, know your KPIs and what each of them measures. Such as if someone asked you to measure something, which KPI would you use?  Like a majority of the exam, the questions do not straight-out ask you what they measure, but present you with a situation and ask you what metric you would use in that situation.

Another area to focus on would be the various portals and their differences and similarities.  For example, Customer Portals allow people to self-register, but Self-Service Portals and Partner Portals do not.

Overall, I feel very confident about my knowledge of the Salesforce Service Cloud and the additional experience that I received during November and December really helped.

Thanks to everyone who made it to the first Chicago Heroku User Group meeting last week at the DePaul Center in downtown Chicago.  It was very generous of DePaul and Heroku to host the first meeting, and very kind of Kavindra Patel to select Chicago as the site of the first Heroku User Group meeting outside of Silicon Valley.  I would also like to extend an extra thank you to our two presenters, Wesley Beary (@geemus) and Corey Haines (@coreyhaines) for presenting at the meeting last week.

Ideally, we would like to hold a User Group meeting about once a month.  In order to do so, we need topics to discuss, presenters to lead the discussion and a location for the meetings to be held.  An initial list of topic for future meetings was compiled at the meeting last Wednesday, which included:

• Other Languages that Heroku supports, outside of Ruby
• Add-Ons for Heroku
• Lightning talks by Heroku users and their real world experiences with Add-Ons
• Partners who have developed an Add-On and how it can best help
• Actual / Real World Uses of Heroku
• Monitoring Applications and Processes built on Heroku
• The different databases that can be utilized with Heroku
• How to build applications with background processes/services using Heroku and its Add-Ons
• How Heroku is Erosion Resistant, and building applications that utilize that resistance
• The pains and thought processes that people have experienced when using Heroku

If you didn’t attend the meeting last week and you have ideas for topics that you would like to be discussed, or if you attended and thought of a topic since the meeting, please leave a message on the Chicago Heroku User Group Meetup.com site or email me at jonathanbaltz@gmail.com.

Also, if you would like to present on a topic listed above, or a new topic, or if your company would like to host a User Group meeting in the next few months, please email me with the details and we can get more of these meetings on the schedule.  I would also like to discuss some integrated meeting options with the ChicagoRuby group, the Chicago node.js group, and maybe the Chicago-Area Scala Enthusiasts (CASE) Group and a database group or two.

Thank you everyone!