If you are using TFS for version control and you check labels in and out, you know the labels can be confusing. What happens is, when you create a new label while under version control, the label is assigned a temporary label which will be something like @$AA1234. The permanent label is only assigned once you check-in the label file. The reason you get a temporary label is so the ID’s can be generated in consecutive order across multiple developers. For example, when developer A checks in, his labels are assigned ID’s 1 and 2. If developer B checks in a little later, her labels are assigned 3 and 4. All 4 labels remain temporary until check-in time because that is when the next available ID value is known.
This timing of the assignment of permanent label ID’s creates some challenging scenarios. For example, let’s say you created a new label which has a temporary value and you modified a form to use that temporary label. If you check-in both of these objects, the label file and the form, at the same time everything will work out great. The label will be assigned its new value and your form will be automatically updated to use the permanent ID. This is the happy path scenario.
Now let’s say you check-in the form but not the label file. At the time you check-in your form, the permanent value for the label is not known and your form will contain a temporary label that is not useful. In that scenario you need to check-in your label file, get the permanent label ID and then re-modify the form plugging in the permanent ID.
The third scenario is, you check-in the label file but not the form. In that case, your labels will be assigned their permanent values at check-in time, and while your labels are being checked-in, AX will update your form with the permanent label ID. Everything is fine and no further actions should be needed.