How to Make Your Automated Communications More Powerful – Through Conditional Data Tags

Automated communications are only as good as the data they carry. In Civica Cx, built-in tags go a long way - but only so far. What if you want to pull in precise, situation-specific data into your emails, letters, or texts? That’s where Conditional Data Tags come in. And once you understand them, you’ll wonder how you ever managed without them.

Why Conditional Tags?

Out of the box, Cx provides a limited set of built-in tags. But modern workflows demand flexibility. Its far too limiting to be constrained by what the Cx BA thought you'd want many many moons ago. I've often wondered.....of the thousands of data tags already available....how many have actually never been used? Have you ever used 'Contact Companies Comma Separated for example'...I suspect not. They return values, and you don't always want just a value - you might want it formatted, or summed up, or wrapped in logic (if...then...else), you might want a concatenation of values.

But some real life examples I've created solutions for:

• “Your balance is £55 in credit”.

  • Don't tell them the in credit folk that their balance is £-520....it doesn't go down well! Instead wouldn't it be nice to write 'in credit'

• “Your 4 weeks rent will be £390”

  • Let people know on termination what they still need to pay. Ultimately, do the sums for them.

• “A Plumbing repair has been reported in your block”

  • This was a brilliant use case to tell tenants in a block if a communal repair had been logged. You don't want to give all the detail on a text...they're limited to 160 characters and the costs add up so just tell them the Trade.

• “New ASB incidents recorded on cases A123, A199”

  • Another fantastic example of being proactive - an internal scheduled comm that lets Housing Officers know if a new ASB Incident has occurred in their area (functional unit)

With conditional tags, you can create rules to extract exactly what you want. There's a simple method of doing it in the front end with if...then...else, but ultimately, it is still limited, You can't map across to 'loosely' related entities, perform calculations, compose strings exactly as you wish. It ultimately relies on returning values from wherever it lives in the system - By hooking in to a stored proc however, you can display what you want, exactly when and where it matters - in a letter, and email or on a text message - Less manual entry. Fewer errors. Better quality communications.

Another Real-World Example: Pulling Information Field Responses

I recently helped a Scottish local authority improve their damp and mould case process. During the case setup, tenants were asked questions like:

• Which rooms are affected?

• Who lives there?

• Where do you dry your clothes?

  
  

Simple info, but incredibly valuable in a follow-up email. Rather than retyping or losing that detail, wouldn’t it be ideal to have it pull through automatically?

Yes—it would. And yes—you can.

Each information field you capture can be configured with a unique data tag name. When you define your communication templates (for letters, emails, or texts), you reference these tags. Behind the scenes, your system administrator or DBA can configure a stored procedure for each tag to fetch the relevant data. Better still, check out this blog post where I've given you one procedure that returns any information field...

Maximizing Communication Impact with Information Field Responses

This gives you incredible flexibility: Want to pull in the latest rent charge? Add a tag. Want to include the tenant's response to a complaint? Another tag. It's modular, powerful, and scalable. You get the picture...I love conditional data tags!

The SQL Bit (For the Curious)

Let’s look at an actual stored procedure for calculating a tenant’s four-week rent. Now before anyone questions my logic, formatting, lack of capitalisation or anything like that, its a working example - your case might (will) be different!

create or alter PROCEDURE [dbo].[usp_DataTag_FourWeeklyCharge]
    @commdefinitionid NVARCHAR(MAX),
    @conditionalTagId NVARCHAR(MAX),
    @entityid NVARCHAR(MAX),
    @tagContent NVARCHAR(MAX) OUT
as
begin
    set nocount on;

    declare @ReturnValue NVARCHAR(MAX)

    set @ReturnValue = (
        select sum(race.Value) * 4
        from (
            select 
			    max(AgreementChargeId) as MaxAgrChgId
            from RentAgreementItem rai
            inner join RentAgreementCharge rac 
				on rac.AgreementItemId = rai.AgreementItemId
            where rai.AgreementId = @entityid
        ) maxChg
        inner join RentAgreementCharge rac 
				on maxChg.MaxAgrChgId = rac.AgreementChargeId
        inner join RentAgreementChargeElement race 
				on rac.AgreementChargeId = race.AgreementChargeId
    )

    set @tagContent = isnull(@ReturnValue, 0.00)
end

You can see in that example, I only use the entityId - in this instance...the AgreementId. I don't care about any of the other input tags, but they have to be there in the procedure declaration.

Once your database team has deployed it, you can reference it in the communications definition Conditional Tags screen, and you’re off to the races.

Note the procedure name here.

You can then bring that tag in to the letter, email, text. They appear at the top under the main entity.

What to Watch Out For

Conditional data tags are powerful—but not magic. Here are a few things to be aware of:

• One-to-many scenarios: Be mindful of tasks that repeat—return the latest, or the most relevant. At best when the comm generates it will crash, worse, you'll get the first or last value back. So make sure to think what am I returning. Even if something shouldn't happen, eventually it will, so code for it.

• Cancelled or bypassed things (tasks, actions, rent actions): Filter these out where appropriate. You probably don't want these.

• Max length: Conditional tags are capped at 256 characters. I'm sure there's a reason - whatever the reason is...I don't like it! But you can do a lot in 256, and if you need more, add another!

• Changing column names: This doesn't tend to happen anymore, but if you rename, add, or remove a field, the system won’t automatically update your tag logic. also if you rename your proc after you've added it to the conditional tags screen, you'll need to change it in there too.

Always impact-assess config changes. You all have Change Boards right?

Final Thoughts

Conditional Data Tags bridge the gap between static system templates and rich, dynamic communication. Whether you’re confirming rent, following up on repairs, or summarizing a complaint - you’ll communicate smarter, faster, and better.

If you're looking to push your Cx communications to the next level - or if you're just curious whether you can do something - get in touch. I love a challenge - the harder, the better. 😊

Want more posts like this? Let me know in the comments what topics you’d like to see next: More stored procedure patterns? Troubleshooting tips? I’m all ears.