Is it better to limit CTA reasons to specific CTA types, or leave them as global? I'm having a hard time divining what our reporting needs will be 6, 8, 12 months from now, and it seems that it's extraordinarily difficult to change your CTA type/structure later, as you can't delete or deactivate any types or reasons that are in use by a CTA. We're fresh enough in to this that we could go either way, but I can imagine how hard it would be to try and move all your global reasons under specific CTAs 6 months later when there are hundreds or thousands of CTAs using those reasons.
Part of what's tripping us up is that CTAs made off time-line entries all default to type "activity" and don't have a reason unless you go back and add one later. There's a fear that if, for example, we move all the 'risk' reasons under the 'risk' CTA types, we would never be able retroactively categorize Timeline To-do's as risks. Is that a valid fear? Is there ever a use-case where people have tried to go back and add reasons to their timeline to-do's? Is it better to keep your risk reasons contained under the risk CTA type, or is it not really a problem if someone makes a lifecycle CTA and gives it a reason 'Bugs risk'?
Not really sure the best path forward here, or what we'll be kicking ourselves for later. I'm trying to avoid a herculean data cleanup in 6 months where we blow away hundreds of CTAs and recreate them under a new data structure.
Best answer by john_appleView original
For manual risk identification, we advise our CSMs to create the appropriate CTA using the RISK type, and then capture any Timeline entries through the CTA. We advise them to use the general timeline and tasks created via Timeline for more routine items. This way we can ensure a single process for Risk tracking.
Others may have other ideas, but this is how we have done it.
Timeline Activity in our Organization has typically been used for email logging from CTAs and Email to Timeline. We also have setup unique Time Activity Types for various uses - sometimes to track a singular issue or other one-off scenarios.