If a player no longer has enough cash to pay the rent, they must sell houses or properties, or take out mortgages on properties.

In this episode, we’ll build a flow that allows players to top up their cash balance by:

• taking out a mortgage on streets with no houses on them
• selling streets with no houses on them to the bank
• selling houses back to the bank

To know which streets have no houses, we first need to get all the player's Assets.

Since taking out a mortgage or selling the property back to the bank is only allowed when there are no houses on it, we filter this collection based on the number of houses.

Number of Buildings is a new formula field on the Asset object that displays the number of houses built on it as a numeric value. For a hotel, the value is 5. Having the number of houses as a number rather than text is much more convenient for flows like this, since we work with addition and subtraction when buying or selling houses. In hindsight, it would have been better to design it this way from the start instead of using a picklist for the buildings on the property.

Since we want to offer the player the options to take out a mortgage, sell properties, and sell houses all on one screen, we also include the flow ALF – Count Player’s Houses and Hotels here as a subflow, which we created in the previous episode.

The Building Transactions that come out of this flow as output may also include cities where the player owns all the properties but has no houses built. Since we only want to sell houses here, we can filter out any Building Transactions that don't include houses.

In the flow, we’ll need to check at several points whether there are any houses and/or properties available to sell.

To do this, we count the number of records in the filtered Assets and Building Transactions collections.

We use these two numbers right away to check whether we should even show the player the screen where they can sell houses and properties. After all, if they don’t own any houses or properties, there’s no need to show it.

If the player no longer has any assets, the N path leads directly to the final screen of the flow.

In this screen, the player either sees that their Cash Balance has become positive again through the sale of properties and houses, or that they’ve gone bankrupt. This final screen is also used when the player has managed to reach a positive Cash Balance again through selling.

If the player does have assets to sell, they’ll be taken to the screen where they can enter what they want to sell or which properties they want to mortgage.

The Sell or mortgage streets section is only visible when the player has Assets (properties) without houses. The same applies to the Repeater located below it.

The text and selection options in each repeater element are also conditionally visible. If there is already a mortgage on the Asset in question, the player can only sell the Asset—and only for half of its value.

If there is no mortgage on the Asset yet, the player also has the option to take out a mortgage. In that case, the player receives half the value of the Asset from the bank.

Below that, the player will see an option for each city where houses are built to sell up to the maximum number of houses present in that city.

To do this, we set the maximum value for the slider to the number of houses built in the city, just like we did in the flow where the player can buy houses.

After the player’s choices have been collected on this screen, the sales can be processed. We start by processing the mortgages and property sales.

Since ownership must be transferred to the bank when selling to the bank, we first need to retrieve the correct bank for the Game in question.

Next, we evaluate each Asset in a loop over the Repeater elements.

In the Repeater element itself, the user has chosen either to take out a mortgage on the Asset, to sell it to the bank, or to take no action.

The Repeater element contains only limited data about the Asset: the Record Id and any information visible to the user within the element itself. So, to retrieve additional details about the Asset and to update it, we need to filter the original collection of Assets without buildings. We do this by filtering on Id equals the Id from the Repeater element.

We also run a loop over this filtered collection of 1 Asset. Within this inner loop, we have access to data from both the outer loop—what the user entered in the Repeater—and the inner loop—the Asset itself.

Selling to the bank

When the Asset is sold to the bank, we need to make the following updates:

• The Player's Cash Balance is increased with the Asset's value
• The Bank becomes the new owner of the Asset
• If there is a mortgage on the Asset, it is removed.

Note: If there is a mortgage on the Asset when the player sells it to the bank, the player only receives half the value of the Asset. This is handled using the formula AssetSalesPrice.

The updated Asset is added to an update collection, so that we can perform the actual database update in a single operation after all loops have completed.

Taking out a mortgage

If the player doesn’t sell the Asset to the bank but instead takes out a mortgage on it, they retain ownership of the Asset but receive only half of its value in cash.

For an Asset worth €20,000, the player receives €10,000 in cash and is no longer allowed to collect rent when other players land on that property.

Ook hier voegen we de bijgewerkte Asset toe aan de updateAssets collection.

After completing both the inner loop over the Asset(s) and the outer loop over the Repeater elements, we check whether any Assets need to be sold or mortgaged. If so, we update the records in the updateAssets collection and the inputPlayer record in the database.

After this we take care of any houses to be sold to the bank.

Selling houses to the bank

First, we check whether the player had any Assets with houses on them. If not, there’s no need to review them per city (Asset Group). That’s what this first check is for. Decision element.

If the player does want to sell houses, we use a filter element and a loop over the filtered result to retrieve the actual Building Transaction.

If this Decision shows that the player does indeed have Assets with houses, then the Repeater for selling houses was visible on the screen, and the player may have chosen to sell houses. That’s why we then start the loop over the elements of this Repeater.

Within this loop, we can then check per Asset Group whether the player wants to sell houses in that city to the bank.

The principle works the same as with nested loops we've seen before:

• In the filter element we matcht the correct Building Transaction based in the Id in the Repeater element
• This should give us only one matching record, but it is still a collection. Therefore we will still need a loop.
• Inside the inner loop we have all the information from the whole Building Transaction record plus what has been entered by the user in the Repeater.

A building transaction works for both buying and selling, so the quantity for a sale must be negative. That’s why we first set the transaction quantity to 0, and then subtract the number from the slider.

In the same way, we subtract the number of houses the user selected in the slider from the number of buildings already present in that city.

We also assign the amount to be earned from the transaction. The formula below is used for this. When selling houses back to the bank, you receive half of what you originally paid for them. So, the amount to be received is calculated as the number of houses being sold multiplied by half the regular purchase price of houses.

To perform database updates outside the loops, we add the updated building transaction back into a collection.

Next, we use a Decision element to check whether there are any records in the updateBuildingTransactions collection. If there are, we update them in the database.

After this, we use a subflow to apply the effects of the Building Transaction to the Assets and Asset Groups.

Once this has been completed, we can delete the Building Transactions themselves.

Processing the Building Transactions in the subflow

The input variables we pass to this flow are the inputPlayer and a collection of Building Transactions. At the start, we retrieve all Assets belonging to this player.

Right now, we only use this subflow for selling, but we can also use it in the process for buying houses. That way, the same logic can be removed from the main flow of that process.

By identifying standalone subprocesses, you can build modularly. You can create a separate flow for each subprocess and use it as a subflow in various processes where that step is needed. This way, you only have to maintain the logic in one place, rather than in multiple flows that contain the same steps.

The second step in this flow is a loop over all Building Transactions. Within that loop, we filter the player's Assets to include only those within the Asset Group relevant to the current Building Transaction.

Let’s say that after selling, you have 10 houses left in a city with 3 properties. You already know that each property must have at least 3 houses, and one of them will have a fourth. Naturally, we don’t want to loop over each property 3 or 4 times—so we use a formula to first determine this greatest common factor (in this case, 3).

The formula for the number of houses that must be placed on each property, at a minimum, is:

When we use the numbers of the example above the formula works out as follows:

10 / 3 = 3,333, but we will round this down, so the answer is 3.

With this formula, we can already assign the first three houses to each property in the city, but we still need to distribute the ‘remainder’. That’s what the formula below is for. Using the numbers from the example, it works like this: 10 – (3 * 3) = 1.

We'll do the following with this:

• We assign the result of this ‘remainder’ formula to a number variable.

• The loop passes through each Asset only once
• 3 houses are assigned to each Asset

• While the 'remainder' is still greater than 0, one extra house is assigned to that street.

• From this remainder value, we subtract one in each loop iteration where a house is assigned to a property. In this example, we assign 4 houses to the first property and then subtract 1 from the remainder value.
• For the second and third properties, the remainder value is no longer greater than 0, so these properties don’t receive a fourth house.
• The buildingsEquallyDividedText formula assigned here to the Buildings field is a result of the decision made at the very start of the series to make that field a picklist with text values. It wasn’t until later that we added the Number of Buildings field, but by then, various parts of the functionality were already dependent on the Buildings picklist field.
• And of course, within the Assets loop, we add each Asset to a collection so that, once the loops are complete, we can update all the Assets in one go.

After finishing the Assets loop, we’re still within the loop over the Building Transactions. We update the player’s Cash Balance per Building Transaction—so this happens after the Asset loop is closed, but still within the Building Transactions loop.

After finishing the Assets loop, we’re still inside the loop over the Building Transactions. We update the player’s Cash Balance for each Building Transaction—so this update takes place after the Asset loop has ended, but still within the Building Transactions loop.

Since we’ll never trigger this flow when there are no houses to buy or sell, we can skip the null checks here. However, in day-to-day practice, it’s always a good idea to include them.

Null checks in short

The pink elements in flows can cause failures if there’s an issue with the data, such as:

• A variable is used as a filter in a Get element, but it doesn’t have a (valid) value.
• De flow probeert een update uit te voeren op een record collection variabele waar geen enkele record in zit.
  • En dit geldt hetzelfde bij aanmaken en verwijderen van records

By checking in advance whether those variables are not empty, you can prevent the database interaction from being attempted when you already know from your check that it would fail.

Back to the screen flow

The section above that handles processing the transactions is part of a subflow. Before we dove into the subflow, I already showed that we also delete the Building Transactions after they’ve been processed by the subflow.

Here, I’ve added a Fault Path from the delete element. A delete action can also trigger an error if it's instructed to remove records that have already been deleted. If something like that happens—perhaps due to another flow or a well-meaning admin cleaning up data—we want to make sure the flow doesn’t crash. The Fault Path, just like the regular connector, leads to the next Assignment, where we clear the Building Transactions record collection variable in case the player needs to go through the flow again.

Why should the player have to go through the flow again?

While the player is selecting which properties to sell, where to take out a mortgage, and how many houses to sell, we can’t immediately calculate the proceeds using screen actions—so we also can’t validate whether the player will reach a positive balance as a result. This is partly because screen actions can’t be driven by data from a Repeater.

It’s possible that the player sells some properties and houses, but the proceeds still aren’t enough to reach a positive Cash Balance. In that case, the player will need to be taken back to the input screen and choose what to sell next from the remaining properties and houses.

The player must not reach the end of this flow until their Cash Balance is positive again. We enforce this with a Decision element. Only when the player’s Cash Balance is greater than 0 are they allowed to proceed to the Final Screen. If not, they are sent back to the start of the flow. In this new round, the flow looks at the player’s current assets and Cash Balance—so selling the same items twice won’t happen.

The final screen

In the end, the player always reaches the final screen—either because they have regained a positive balance, or because they still have debt after selling all their assets. We’ve already created that final screen and the path to it in the case of bankruptcy.

How does this flow fit into the bigger picture?

This flow must be triggered immediately when the player has a negative Cash Balance. Since the player’s entire turn is executed within the SCR – Roll and Move flow, we’ll need to insert this flow somewhere within that main flow.

In addition, we need a way to trigger the flow if the player goes into the red outside of their own turn—for example, if a Chance card requires them to pay money to another player.

Finally, we need to ensure that a player who is bankrupt no longer gets a turn.

The first point where the player might go into the red is when leaving jail by paying €5,000.

Next, after these two existing Decisions that check whether the player’s Cash Balance is still positive.

To prevent a bankrupt player from taking another turn, we’re going to do the following:

• We’ll add a new checkbox field called Bankrupt to the Player object.
• In the SCR – Sell Buildings or Assets flow, we add an update to check this box when the player is bankrupt.
• In the ALF – Start next Player’s Turn flow, we add a condition to the Get elements that fetch the next player—ensuring they are not marked as Bankrupt.

Next time

In addition to selling assets back to the bank, you can of course also sell them to other players. That’s what we’ll be working on in the next episode.