Best practice for unwanted objects

Certified Associate Developer

Hello ,

Any best practices around how do we manage objects which are not required anymore ?

Specially when those objects have been previously deployed to production. 

Is it a best practice to delete such objects ? If this could be an option , then such objects could be easily deleted in the development environment but then how do we promote the deletion to high environments ?

Or someone will have to manually delete them in the high environments ?

Thank you. 

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Senior Developer

    Deleting objects is not recommended I guess. I would add the description as deprecated and Update the name of the object with DEP_objectName etc and then remove/erase the code from the objects and deploy it to higher environments.

  • 0
    Certified Associate Developer
    in reply to Konduru Chaitanya

    Thanks Kondaru.

    Is there a reason why the object deletion should be avoided ? Specially when we are sure that it does not have any dependents(not being used)

  • 0
    Certified Senior Developer
    in reply to sagarc3658

    There is no compulsion that you should not delete the objects on any environments. Its just that you need to make sure that there is no dependencies on those objects that you are planning to remove. When it comes to Higher environments the usual developer who makes the developments in dev would not have access to Prod (In most cases), there would be separate teams to handle the things in the Prod. So to avoid any mishaps in case the person deleting the objects has low level of awareness of the dependencies. Some applications might use the UUIDs stored in database to trigger processes or any sort of action related to the objects, this would break if no proper handling is done and the rule or logic is looking for that UUID object. For instance lets say there are few API which have no dependencies in the application but the object is being used by some third party, this will also break. Any of this will be avoided if the objects were initially marked as DEP or moved into a separate folder. 

Reply
  • 0
    Certified Senior Developer
    in reply to sagarc3658

    There is no compulsion that you should not delete the objects on any environments. Its just that you need to make sure that there is no dependencies on those objects that you are planning to remove. When it comes to Higher environments the usual developer who makes the developments in dev would not have access to Prod (In most cases), there would be separate teams to handle the things in the Prod. So to avoid any mishaps in case the person deleting the objects has low level of awareness of the dependencies. Some applications might use the UUIDs stored in database to trigger processes or any sort of action related to the objects, this would break if no proper handling is done and the rule or logic is looking for that UUID object. For instance lets say there are few API which have no dependencies in the application but the object is being used by some third party, this will also break. Any of this will be avoided if the objects were initially marked as DEP or moved into a separate folder. 

Children
No Data