What the problem?
Yes normal behavior. The only steady ID is the GUID
3 Likes
Basic relational database behavior
4 Likes
We can start with a classic example.
Letâs say Marcel and I are working on a project together. Because computers canât both work on the same file at the same time, Revit allows worksharing, where a central file takes a record of everything which we do, and tracks new elements and changes to existing ones which are first performed in a local file, and then synced into the central. Starting in a blank central file, Marcel creates a new local, which pushes the entire contents of the central into a local copy on his C drive. This is an empty file (well conceptually - you canât have an empty file), but he begins to add content into it. These changes are placed into his local copy, saving as he might like, but no changes are made to the central. When he finally syncs to central, any changes to the contents on the central file are pushed to his system, then any changes he has made are pushed to the contents in the central file, and finally any new content is added to the central file. Hopefully this makes sense.
With element IDs, each needs to be unique or Revit wouldnât know if youâre referring to this thing or that thing. They are given in sequential order, where each thing you make is one more than the previous. Note that some things require something else is made first - ie: a floor needs a floor type, a sketch, and sketch lines that create a closed loop before you can make the floor element, so your simple âboxâ floor with an existing type might be 5 or 6 element IDs separated from the prior created content. Hopefully this also makes sense.
Now, onto why they have to change.
Say Marcel and I are both working on the blank project. He creates a new local on Tuesday at 9am and begins drawing the first floor, and I create a new local on Tuesday at 9:05 and begin drawing the second floor. Weâre telepathic so our work will perfectly coordinate on top of each other. In Marcelâs local file the first element he creates is the next one in the local copy of the central, element 1078, and an additional 20 elements so element IDs 1079âŚ1098 are used in his local. In my local file the first element I create is the next one in the local copy of the central, element 1078, and an additional 30 elements so 1079 to 1108 are used in my local. The first number is the same for both of us as weâre both working on our own independent copy which is created from the same data.
We typically sync every 20 minutes, but at 9:15 Marcel gets a call from a client who has some questions on the latest design, so he doesnât sync at 9:20. I donât get a call so I sync at 9:25, and the central sets element IDs 1078âŚ1108 to the new content I sent over.
At 9:35 Marcel syncs. The central sends him the 31 elements I created as IDs 1078âŚ1108, and the conflict is instantly clear. To prevent this his elements are given the IDs 1109âŚ1129, and then sent to central. Every one of his IDs is different than when he created it, but all content otherwise remains static.
There are other aspects of the Revit DB which can cause the ID to change, but this is the least technical of them and only one I have seen reliably happen.
Hope this helps. 
4 Likes
Great explanation 
1 Like
Just wanted to point out as we are speaking about the âGUIDâ . few days back I realized that Guids can also have clashes ( multiple elements having same Guid). I tried to extract GUID of a Document and was suprised to know that some documents created with same templete share a common GUID.
Read More here : Solved: How do you access a model's GUID or UniqueId using the Revit API? - Autodesk Community
1 Like
Yes - GUID is created at the time of creation, and since those template items were created once, they get matching GUIDs.
This is handy to find out what template was used in a project.
Also, if anyone performs a save as (day of a model goes corrupt) the GUID is maintained.