Fantasy Football Draft Application

Building the data model

During the development process, I experimented with several different data models for the draft application. Initially, I considered using the built-in Account object to represent teams and the Contact object to represent players. However, for the final version, I decided to create custom objects for these entities to ensure that the application could be easily imported into any Salesforce organization without causing conflicts with any existing setup. In terms of managing the draft data, I ultimately chose a simple, flat structure and relied on Apex and JavaScript to handle the complex logic of organizing the picks into rounds and determining which team had each pick. This approach resulted in the creation of four custom objects to store the data.

Below is the final data model I went with.

Setting up the APIs

With the data model in place, my next task was to set up the API calls to My Fantasy League to retrieve the necessary data and populate the records. While I won't go into detail about each individual API, I will mention that I used the following five exports to gather the data. (You can find more information about these exports in the My Fantasy League documentation.)

• nflByeWeeks
• players
• adp
• playerRanks
• league

Since the API callouts were essentially the same except for the URL, I created a single method to handle the callouts and passed the URL as an argument. To avoid hardcoding values such as the base URL, I stored them in Custom Settings (GHL__c).

I divided the exports into three groups and created separate classes to manage the responses and upsert the relevant records in Salesforce:

• The Bye Weeks (MFLManageByeWeeks) class served two purposes: it provided information about the bye weeks for each team, and it also allowed me to capture all of the NFL teams and upsert them as NFL_Team__c records in Salesforce.
• The Players (MFLManagePlayers) class handled the players, adp, and playerRanks callouts and was responsible for upserting the related Player__c records in Salesforce.
• The Owners (MFLManageOwners) class gathered information about the franchises and owners in the league and was responsible for upserting the corresponding Team_Owner__c records in Salesforce.

Building the draft board front end

This is the central component of the draft application. Initially, the draft was controlled from a single page that required login and was intended to be shared via screen sharing with virtual attendees. However, in a later iteration, I transformed it into a read-only view of the draft that was publicly accessible to anyone in the league, allowing them to follow the draft in real-time from any location. The page was dynamically updated whenever a pick was made using the new Commissioner page.

To begin with, I needed to determine the number of teams in the draft and the number of rounds. Obtaining the number of teams was a straightforward query to retrieve the number of Team_Owner__c records. The number of rounds is currently hard-coded, but it would be ideal to store it in the GHL__c custom settings so that it can be easily modified. With the number of teams and rounds, I was able to create the structure of the draft board.

Since this is a read-only view of the draft board that does not require user input, we need it to automatically update when the commissioner submits a pick. In a normal scenario, platform events would be the ideal solution and we could use empApi to subscribe to them. However, since we want to make this page publicly available through a community, we cannot use empApi, as it is not compatible with communities. Instead, I used cometD to subscribe to the platform event. This presented a problem because guest users viewing the page do not have a session ID to access Salesforce through the API. To work around this issue, I used a hack to temporarily use my own credentials (stored in Custom Settings) to obtain a session ID. While this is not a secure solution, it was acceptable for my purposes. In a real-life scenario, it would not be recommended.

In summary, the draft board component simply listens for an event and refreshes the data when it is received.

Building the commissioner control panel

The commissioner controller panel is the more complex part of the application, as it allows the commissioner to make, delete, and upload picks. This panel is essential for ensuring that the draft process runs smoothly and that the picks are immediately available for viewing by the rest of the league.

The draft template was constructed in a similar manner for the commissioner view, but it was displayed differently on the screen to suit the commissioner's needs. The commissioner needed three input options: make pick, delete pick, and upload to website.

Setting up the community pages

With all of the components in place, I created a Digital Experience (formerly known as a Community) and added the read-only view of the board to the Home page, making it publicly accessible. The Commissioner Panel was added to a separate page that required login to access. This completed the development of the draft application.

View of Current Draft Board

Final touches

With the remaining time before the draft, I added a few extra features to the application. One of these was a control panel within Salesforce that could be used to update the team and player listings from My Fantasy League to ensure that we had the most current information. I created buttons that called the existing Apex classes that performed the exports to accomplish this.