Getting the best results out of your Broadcasts means planning ahead. Before you start building new Broadcasts, it’s worth taking the time to put the foundations in place so you’re set up for success.
Structuring your People Data
Broadcasts is about sending messages to people - and how you store your people data in Ardoq will determine the benefit you can get from Broadcasts.
We strongly recommend that you store people as individual components in a dedicated People Workspace.
These components then have references to other components that describe their responsibility,
Accountability or relationship to those things.
For example:
Peter (Person component type) Owns(reference type) Business Process 1 (Business Process component type )
- or-
Anna (Person component type) Is Expert In (reference type) Application X (Application component type).
Structuring your people data this way is the foundation for Broadcast’s audience targeting function. Specifically:
It expects a component type called Person.
It expects a Person component to have a field type called email.
It expects a Person component to be stored in one or more dedicated People workspaces.
However, the names of the reference types that link those Person components to other component types are not pre-set. You can call them what you like.
But what if your people data isn’t structured this way?
You may, for example, just hold an email address of an application owner on the application directly. Does that mean you can’t use Broadcasts?
No, Broadcasts will still work - but you won’t be able to exploit its full potential. In fact, you won’t be getting the full benefits of Ardoq in general.
This approach has two big drawbacks:
If a person leaves or changes their role, data will need to be updated in multiple places - and it’s easy to miss one.
You won’t be able to use Ardoq to get a ‘360-degree’ view of an individual person and to tailor views, analysis and communications to their individual needs.
For those reasons, it’s Ardoq’s best practice to model people as components.
To make this easier we also provide our Azure Active Directory People Data Integration as well as Managed Workspaces. These help you plug Ardoq into your organization’s master source of people data and to keep it in sync.
If you need help re-structuring your people data, talk to your Customer Success Manager or contact us via in-app chat.
Planning Your Broadcast
Broadcasts are fast and easy to set up - but that doesn’t mean you don’t need to think them through first.
If you’re planning to regularly message a large number of people you need to be clear on what you want to achieve (and don’t worry - you’ll get a chance to test before you deploy!).
Start by asking yourself:
What is the outcome I want to achieve?
Who do I want to involve?
When do I want to achieve it (or how often do I want to repeat the process)?
For the what, if you want to gather information or keep it updated you’ll need a Survey Broadcast. On the other hand, if you just want to inform someone of something, choose a Message.
If you want people to make dependent updates - or make an update which then triggers a message - then you may need to build a workflow (see Building Workflows with Broadcasts).
Equally important is knowing who you want to involve. Where possible, you should avoid ‘spamming’ your organization with messages that aren’t relevant to the majority of the audience.
So ask:
Do I want to message groups of people or individuals?
If individuals, am I interested in specific people or the roles they perform?
The second point matters, because people join, leave, and change roles in all organizations. Building a Broadcast to send messages to named individuals means that when those individuals move, you’ll need to modify your Broadcast.
On the other hand, if you Broadcast based on rules - specifically a predefined or Gremlin query - then the Broadcast will still work just fine as long as data is kept up-to-date in Ardoq.
Lastly, you need to determine when and how often you want to broadcast.
When simply depends on when you want to start the process. It can be straight away, or at some point in the future. Likewise, you can set an end date for the Broadcast, or keep it running until it’s turned off.
How often is a bigger question: you can adopt a ‘push’ or a ‘pull’ strategy here.
Push means you want to pick up new data as soon as it's available. For example, if your Project register is updated every day, then you may want to message stakeholders to let them know a project status has changed as soon as possible, so you can set your Broadcast to check for updates daily.
Pull means you want to pick up data when it’s required. For example, if you run a six-monthly Security audit of your applications, then you may only want a Survey Broadcast that runs every six months.
Even if the application information has changed in the meantime, your Security team isn’t going to do anything with that data until the next audit, so six-monthly is fine.
For other factors to consider when setting the schedule, see working with timing in Broadcasts.
If you still have questions or need more information, check out our video tutorial, or reach out to us by using the in-app chat.