Team Server merge conflicts and a risky production deployment

Accept mine silently discards work, and here it discards two different intents. Taking mine on the domain model drops the Invoice entity and the CustomerCode rename that B shipped; taking mine on ACT_Order_Save drops B's logic change. Both surface later as either a broken build or, worse, a build that compiles but loses behaviour nobody notices until production.

Resolve in the merge editor, one document at a time:

• Open each conflicted document in the comparison view and read both sides. In the domain model, keep both the new Invoice entity and both renames; they touch different elements, so no business intent actually conflicts, only the XML representation.
• In ACT_Order_Save, understand what each change does before combining. If the two changes are genuinely incompatible, talk to B and agree on one behaviour, then implement it once.
• After resolving, run the consistency check, fix resulting errors, and test the merged branch in a local or sandbox environment before pushing.
• Commit with a message naming the merge and what was kept, so the next person can audit it.

Rules that prevent the situation: merge main into your branch daily rather than after two weeks, keep branches under a week, and avoid two developers editing the same document in parallel. Where parallel work on one microflow is unavoidable, split it into smaller microflows first.

Renaming an attribute is a destructive database change. Studio Pro warns that renaming an attribute drops the existing column and creates a new, empty one. With 220,000 Customer rows, Customer.Name to Customer.FullName and CustomerNumber to CustomerCode means two columns of production data gone. A database synchronization will happily do it because the model says so.

Safer route, in order:

1. Do not rename in the same release as a large feature. Add the new attribute, migrate the values with a microflow, keep both for one release, and remove the old one later.
2. If the rename must ship now, take and verify a full database backup first, and confirm a restore actually works. There is no backup from the last 24 hours, so that is the first thing to fix.
3. Deploy the same deployment package first to an environment that has a recent production-like dataset, not just to an acceptance environment that runs main with a small dataset. The rename behaves differently there.
4. Understand the synchronization: adding entities and attributes is additive and safe; renaming, retyping and deleting are lossy. Deleting an attribute in the model drops its column at the next synchronization.
5. Never build a production package from a feature branch. Merge to main, tag the release, build once, and promote that same package through acceptance to production.

Aim for a short-lived-branch, single-main model with explicit promotion.

• Main line is always releasable. Nobody commits directly to main except for merges of reviewed, tested branches. Feature branches live days, not weeks, and the developer merges main into the branch at least daily.
• Small, owned changes. Split stories so two people never edit the same domain model document or microflow in the same sprint. Where coupling is unavoidable, one person owns the document and the other sends the change as a request.
• Commit hygiene. Commit small and often with messages that say why; never leave uncommitted work overnight, because uncommitted local changes cannot be merged, reviewed or recovered.
• Release tagging. When the sprint is accepted on main, create a tag, build the deployment package from that tag, deploy to acceptance, then promote the identical package to production. No rebuilding per environment.
• Environment configuration outside the model. Keep URLs, credentials and environment-specific constants in the per-environment settings in the Developer Portal, not as values in the model that differ per branch.
• Rollback plan. Keep the previous deployment package and a verified database backup before every production deployment, with a named person responsible for the restore decision.
• Definition of done includes a successful merge of main into the branch, a green consistency check, and a test on the merged result.