3 Minute Features : Episode 4 : Business Rules

Wearing ties is a rule that is just bonkers, and not allowing working from home. Thankfully those in CDS are a little more understandable.

Welcome to the 4th video in the 3 minute feature series, on Business Rules

Episode 4 : Business Rules

Transcript

Starting from the Entity, select Business Rules, Add Business Rule

At the top is some tools which we will use later

The first part is a condition, what combination of fields will make the rule trigger. This can be a combination of fields, either both values or one or more of the values

In my scenario, I am going to worry about the status reason for my thing, mimicking an approval process. So, firstly, is the status reason waiting approval?

Then our first action. I want to make the Approver field business required, forcing the user to enter a value.

Next, make the default value of the log field Waiting for approval. Setting values is very limited, you might want a timestamp here, but this is not possible in a rule.

Next, the 2 approval fields need to be visible, allowing my user to enter the values

Now I have achieved everything I wanted on this condition, lets move to th e next condition. If it is not “waiting approval”, check to see if it is approved

Add a condition to the negative side of the first condition, select eh status reason & a different value

This time, we want to still ensure the approver and the log are visible, but lock them both, stopping once it is approved anyone changing the value

But what would happen if the status reason was switched back to waiting approval from approved? The first condition path does not unlock the fields, assumes they are already unlocked. This should be fixed. The business rule editor allows you to copy actions and conditions. Click on the action, select copy.

The select paste. The rule editor then asks you where to paste it to. Select the + where you want it.

We want an unlock rather than a lock, so swap over the action.

Repeat for the log as well.

We can use this techique to cover all the basis, or the default condition, where it isnt Awaiting approval or approved. Copy the Set Business Required, past on the negative condition. Rename it to show we care about maintenance. Same for the show approver and log actions, with the value set to hide.

Once we are done, hit save. This runs a validate as well, proving that there are no missing parts to the actions or conditions. You can rename the rule by dropping down the top option.

This rule is not active yet, we need to activate it, but first the scope has to be considered. Do you want this rule to apply to any time a record is added or updated anywhere in your system, such as imports etc or just when using a form, or just one specific form.

Finaly, Activate. Once activated, the rule can not be edited, only deactivated.

This is then ready to be tested.

I create a new Thing. The default negative path is running now, hiding both the approver & log fields.

As I change the status reason to Waiting approval, the first postive branch kicks in, showing the 2 fields and making the approver mandatory.

If I move it to Approved, the approver is locked, but the field remain visible.

There are a few more options for you in actions, around the suggestions and warnings, so lets edit the rule by deactivating first.

Lets show an error message to enforce that the approver is required. Against the field and a custom tesxt.

Also, we can recommend a value in this condition for multiple fields.

Under details, you can add one ore more defaults for fields, I will just recommend a title for now

Hit Save, then Activate again and lets see it in action

Where the status reason is waiting approval now, we get an error on the approver field, alerting us we need to fill that in. Also, there is a little light bulb that appears against Name, if you click on it, there is a button for you to fill in the form with the fields that we set up

Back to the business rule, there is a snapshot button. This creates a picture of your full business rule to share with others.

3 Minute Features : Episode 1 : Entities

My hiatus from blogging is due to my lack of creativity around thinking about problems and how to solve them and this got me thinking about a ready source of material that which would give me a infinite number of things to write about.

As I always want to learn, and envy those that do these things, rather than a blog, I have started a video series which does a show and tell on a subject, in a set time frame.

Welcome to 3 Minute Feature Thursdays

Episode 1 : Entities

Transcript

Hi and welcome to the first of a hopefully weekly topic on the fundamentals of the Common Data Service.

There are a lot of blogs and videos out there that are documenting all the changes that are forever coming into the platform, so I thought we should take some time to ensure everyone knows the fundamentals.

I will be diving into a topic each week in some depth, but trying to do it in 2 minutes. This gives me a timeframe to work to, reduces unnecessary words and hopefully gives a refresher or introduction to the topic in a bite sized portion.

The first topic is Entities, so here we go

Firstly, go to make.powerapps.com. Once there, check that you are in the correct environment. This is essential to ensure you are adding components to the right place.

As with all development, it should start with a solution, so using the menu on the left, select Solutions, and new Solution.

Give it a name and a publisher, both allow for the ability to differentiate our solutions and to patch solutions as we move the solution between environments for testing etc.

The default version is 1.0.0.0

Now hit publish, you can see that the solution is empty, so the next step is to create an entity using the menu top left

The display and plural names are used by default in lists and records. The Name is the physical table name in SQL, so can not be changed after the entity is created. The name is prefixed with the publisher prefix.

The primary field is what is selected when the user chooses a record to link 2 records together, like Contact name or company name. You can choose to change the default name and the field name.

As we go down the properties, those with a little cross next to them can not be changed after you set it. You can set it if it is not set, but once it is set, there is no going back

A key checkbox is the “Enable attachments”. This enables the entity for attachments, basically links the notes entity to your new one.

Description allows your entity to be found later on and should describe it’s useage. More documentation the better

If you change the Entity type to Activity, it will be allowed to be treated as an activity, such as email, tasks or call. Great if your entity is a new version of these things.

If you want to restrict access to certain records in your entity, like opportunities typically, then ownership needs to be User or Team. Organisation level is used for data shared across your whole system, such as products.

In the Collaboration section, Allow Feedback links your entity to the Feedback entity, allowing users, external or internal, to feedback and rate a record. Typically used for case or survey scenarios

In the out of the box, meetings can have followup tasks that are associated with them, if your entity fits into this scenario, then enable this.

Connections allow a user to link 2 disparate records together, typically used between employees / contacts / accounts to denote relationships.

If you think that you want to be able to link your entity to incoming emails, then check Send email to Entity. The entity needs at least 1 email field. Leads and contacts are examples of this out of the box.

Mail merge and sharepoint checkboxes enable the corresponding functionality too. Sharepoint needs more configuration, but here is where you enable each entity.

Access teams complement the security via ownership. If you enable this checkbox, and set up a template, an access team for each record is automatically created when via code you add your first user to the team.

Queues are typically used in a service scenario, but allows assignment of your record to a queue to be managed by a helpdesk or group of users.

Quick create forms are useful in a lot of scenarios, where you want the user to easily create a new record with a subset of all the fields.

Duplicate detection is common on most records. This setting enables it, but you will have to configure the rules to prevent duplicates.

Flow change tracking allows Flow to subscribe to “When a record is updated” triggers on your entity. Essential in most scenarios.

The final option is enabling your entity for offline outlook. There is a lot more to consider on this, but here is where you start the journey

Once configured, hit Create and wait. You can go ahead and add fields and other stuff as you wait. Eventually you will be displayed with a nice green banner and a list of the default fields.

So that’s it.

Next time, I will dig into Fields, continuing on our journey.

Please subscribe if you find these useful and provide feedback either via Twitter, LinkedIn or my blog.

Cheers, see you next week.