CRM Team Communication Standards

This article explains how the CRM Team works: how we handle requests, how we keep you updated, what we document, and what you can expect from us. It is written for two audiences — CRM Team members who follow these standards, and the stakeholders, partners, and leaders who work with us. You can also learn more about Salesforce at University of St. Thomas on OneStThomas. This article includes:

What You Can Expect From Us

These are commitments, not aspirations. If we are not meeting one of them, tell us.

Commitment What that means in practice
A weekly update, always Every open ticket and every open development story gets an update at least once a week — even when the update is “still waiting on X.” You should never have to ask whether something is still moving.
Plain language We write for you, not for ourselves. We will not tell you a request was “moved to Jira” and leave it there — we will tell you what that means, what happens next, and who to talk to.
One named owner Every request has a single owner on our team who carries it through to completion. Work that crosses teams is split into tasks so you can see who owns which piece.
A written record Every conversation about your request — a meeting, a call, an email, a hallway chat — gets summarized back into the ticket or story. Nothing important lives only in someone’s inbox.
Documentation on delivery Nothing we build is “done” until it is documented for the people who use it. Documentation is built into the work, not added afterward.
No meeting without a reason Every meeting we run has an agenda. If there are no agenda items by the end of the prior business day, we cancel it and give you the time back.

How to Reach Us

Please use the channel that matches your situation. Requests sent to an individual by email or Teams are easy to lose and leave no record — a ticket or story comment reaches the whole team and stays findable.

Your situation Where to go What happens next
Something is broken, or you need help with an existing system Submit a ticket through TDx Services We triage it, acknowledge you, and tell you what to expect. You get an update at least weekly until it closes.
You want something new built or changed Submit a ticket through TDx Services If it requires development, we scope it into a Jira story. Prioritization is set with your CRM Steering Committee representative.
You want to know where an existing request stands Comment on the ticket or story The owner responds there, so the answer stays attached to the request.
You want to discuss priorities, scope, or strategy Your CRM Steering Committee representative, or a standing meeting agenda Prioritization decisions are made through the Steering Committee, not ticket by ticket.
You suspect a system-wide outage or data issue Alert the CRM Team immediately, then open a ticket Speed matters more than process here. Tell us first, document second.

How We Handle Support Tickets

When a ticket comes in

  • We triage it using our standard CRM Ticket Triage process.
  • We acknowledge the requester and set expectations for what happens next.
  • If the ticket was routed to us in error, we tell you which team can help, reassign it, and pass along anything we have already learned so you do not start over.

While it is open

  • Every open ticket gets a comment at least once a week.
  • If we are waiting on you, we restate the question in a new comment rather than assuming you saw the old one.
  • Every conversation about the ticket — meeting, call, email, or Teams — is summarized into the ticket with the date, who was involved, what was discussed, and what was decided.

How a ticket ends

Outcome What we do
Resolved You get a closing comment that says what changed or what is now working, any action you need to take, how to confirm it is working, and an open invitation to reply if the issue continues. We also record the technical detail for ITS/CRM in the same comment.
On hold We confirm a date with you for when you will be ready to revisit, record the conversation in the ticket, and set the ticket to come off hold on that date. It will not be forgotten.
Cancelled We record the conversation that led to cancelling before we close it, so the reasoning is preserved.
Moved to development We explain that the request needs development work and has moved into Jira, our project management system, and point you to your CRM Steering Committee representative to discuss prioritization.

How Development Work Runs

Requests that need to be built rather than configured become Jira stories. Every story is scoped using the CRM Jira Request Template — that is the standard, not a suggestion.

Who owns what

  • The Admin or BA who scoped the story owns it through deployment. That person is your point of contact from start to finish.
  • Developers are assigned build subtasks. Developers do not own stories or status updates — so you always have one owner to ask, not a rotating cast.
  • Admins create fields, handle permissioning, and guide stakeholders through testing.

Where information lives

Field What goes there Rule
Description Summary of the request. Updated only when scope changes. If the Description changes, the subtasks are updated to match.
Comments Clarifications, meeting notes, questions, decisions, and email or Teams conversations. The Admin summarizes and cleans up comments so the story stays readable.
Subtasks The actions that need to be taken. Requirements are outlined in each subtask. Detail lives here, not in the Description.

Every story is updated weekly

  • The Status Update and Status Update Date fields are updated weekly with one to two sentences — enough to know where things stand without opening the story.
  • Meetings, email, and Teams conversations about the story are recorded as comments.

Where work gets built and tested

Every project gets its own dedicated development environment. This keeps our shared STAGING environment clean and protects in-flight work when STAGING is refreshed.

Step Who What happens
1 Admin Spins up a Dev org for the project using Sandbox Seeding templates, and builds there first — creating fields and permissions.
2 Developer Pulls from the Dev org into a Scratch org and does the build work there.
3 Developer Pushes the completed build from the Scratch org to STAGING.
4 Admin Tests in the Dev org until the work is solid, then promotes to STAGING when it is ready for you to test.
5 Admin Demos the work from the Dev org.

Testing

  • Testing instructions live in Jira, and the link is provided in the story.
  • We tell you what needs testing and how to test it. We do not assume you know where to look or what “working” should look like.
  • The test plan is defined as its own subtask, and testing is executed under its own story — so it is real work with real time allocated, not an afterthought.

Required on every development story

No story is considered complete without subtasks for each of these:

  • Permissions
  • Creating or updating the TDx knowledge base article
  • Experience Cloud work — two articles: one for the student/alum portal view, one for staff supporting the process
  • Security review
  • Test plan
  • Visio diagrams for workflows and processes, where applicable

How We Document Our Work

Every project produces two kinds of documentation

Audience What it covers
CRM Team How we support and maintain it — configuration, owners, admin steps, dependencies, known failure points, and how to troubleshoot.
Users How the business uses it, written in your language and your workflow. Experience Cloud work gets two articles: one for the student/alum portal view, one for staff supporting the process.

These are separate deliverables. One never substitutes for the other — a technical runbook is not user documentation, and vice versa.

We document the whole process, not just our piece

  • Every project documents the end-to-end process the work sits inside, not only the part we built.
  • A Visio diagram is included wherever the flow is non-obvious or crosses teams or systems.
  • Process documentation is a required subtask, not a post-launch cleanup item.

Recurring questions become articles

  • If we answer the same question a third time, we write the article.
  • We prioritize ticket categories that have no article yet.
  • When we close a ticket, we link the relevant article so you have it for next time.

Which tool holds what

Tool Used for Rule
TDx Knowledge Base All published documentation — team-facing and user-facing. The system of record. If it is not in TDx, it is not documented.
Visio Any diagram — process flows, data models, integration maps, org structures. The diagram is embedded in the TDx article; the source file is linked in the Jira story so it stays editable.
Jira The request, requirements, decisions, and work history. Jira is not a documentation library. Finished documentation belongs in TDx.

How We Run Meetings

Agendas

  • Every meeting has an agenda. No exceptions.
  • For recurring meetings, agenda items are captured in the Teams OneNote notebook.
  • For ad hoc meetings, the agenda goes in the invite — including why each topic is relevant to you (“You were invited because…”).
  • If there are no agenda items by the end of the prior business day, the meeting is cancelled.

Attendance

  • We decline meetings we will miss, with a note. Silence reads as attendance.
  • If someone who owns a recurring stakeholder meeting is out, they either cancel it or delegate a teammate to run it — it does not silently lapse.
  • We invite one representative per team who can speak for that team, including ours.

Scheduling

  • Meetings we own start five minutes after the hour or half hour.
  • We do not book the full hour or half hour — we end early so you can reach your next meeting and take a break.

Glossary

Term What it means
TDx TeamDynamix — the university’s IT service management system. Where you submit requests and where all published documentation lives.
Jira Our project management system, used for development work that is larger than a configuration change.
Story A unit of development work in Jira, with a single named owner and a set of subtasks.
Admin / BA Salesforce Administrator / Business Analyst — the CRM Team roles that scope requests, configure the system, and own stories through delivery.
Dev org / Scratch org / STAGING Separate Salesforce environments used to build and test work before it reaches PROD, so changes are never tested on live data.
Experience Cloud The Salesforce portal technology behind student- and alum-facing pages.
CRM Steering Committee The group that sets priority across CRM requests. Your representative is your route for prioritization conversations.

Questions About This Article

If something here does not match your experience working with us, that is worth telling us — open a TDx TechDesk by emailing salesforce@stthomas.edu or raise it with your CRM Steering Committee representative. 

Print Article