Personalized Community is here!
Quickly customize your community to find the content you seek.
Microsoft Customer Co-creation
Help impact how the tools and services you rely on are developed. Microsoft Customer Co-creation connects you directly with our engineers so you can provide feedback before a single line of code is written. Interested? Learn more at Microsoft Customer Co-creation
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
To start with I might need to explain the use of the word hack. About a month ago I recorded a chat with Scott Durow for his Power Platform Unpacked video series. He pointed out that the word hack has a negative ring to it in the world of developers. He was referring to the use of it as something you use as a ugly workaround for something you couldn’t solve in a sustainable way. And yes – that is a reasonable association.
I see it more as in the term of a “Life hack” – something to help you be creative in ways you wouldn’t usually be. So I went to the Urban Dictionary and found the definition I like a bit better:
A clever or elegant technical accomplishment, especially one with a playful or prankish bent. A clever routine in a computer program, especially one which uses tools for purposes other than those for which they were intended, might be considered a hack.
Now that’s more like it! These hacks I presented as a session, and write about, is really just meant to be inspirational ways to use configuration to solve requirements without using code. Whether you want to use these hacks in a solution or not is up to you, your situation and your views on technical debt (which is a completely different blog post). Now enough with the jibber jabber and let’s take a look at the actual hack!
To start with we have an Event and an Event Registration entity. The Event has, not very surprisingly, a start and an end time.
The requirement is about having a user friendly way to make sure that a contact that is not of age does not get registered as a participant to the Event.
The only information OOB (Out Of the Box) that refers to how old a Contact is, is the birthday field, not the actual age it self. I need to somehow transform the birthday into a number, which leads me to challenge number two.
If I were to use Birthday on contact in a calculated field and either use the DiffinYears or DiffinMonths, it would not be precise enough. The reqirement is not that the participant should be of the right age that year or that month. It has to take the exact day into consideration. Okay – but what about DiffinDays? Which lead me in to challenge number three.
Back in the days Julius Ceasar and his posse of astronomers decided to add an extra day ever fourth year to even out those extra hours it takes for the earth to fully revolve around the sun. Kind of reasonable – we don’t want to end up celebrating Christmas in the middle of the summer. But still – it kind of screws up calculating age in Dynamics. So I can’t use Diffindays divided by 365 days either. Thanks Julius.
But at least Julius Ceasar was consistent. A leap year every fourth year is something I can work with. So this is how I solved it.
I start with making sure that the Birthday field and the Events Start date have the same field behavior. If they don’t, you won’t be able to use Diffindays with these field.
I then create a calculated field on the Event Registration that calculates the age at the time of the event for the participant. I will have to use a Decimal number with ten decimals to make sure it’s precise enough. I will divide the Diffindays by 365.25 to take the leap year into consideration.
I will then create a real-time workflow that runs on Create of the Event Registration, compare the Age limit at the Event entity with the calculated field.
If the age limit is greater than the age at the time of the event I’ll cancel the workflow with a message telling the user that the participant is too young to be registered.
Obviously, this being a 10-decimal field I would not put it on the form for the user to see (because it’s ugly). But for your eyes only I’ll make an exception.
And that’s it! Now we’ve achieved a way to handle age limit at events. If you were to implement this you would need to consider if there is a chance that an events start date ever changes, and how that would effect already booked participants.
Interested in learning more hacks? Read about my most popular hack here – Get Fields From Related Records Using Actions
Business Applications communities