Normally when a user leaves the company, you're going to delete the user's Person document from the NAB, add their user name to the Terminations group, and admin process will update all files that they may have had access to to remove them. Depending on how your server security is set, adding them to the Terminations group ad removing them from the NAB will prevent them from contacting the server and/or replicating and/or sending mail and/or signing onto Traveler or iNotes.

However, If the local machine in question is a user's personal machine, then there is not a lot you can do, because, unless the machine again contacts the server, it will remain in the state it was when they left; so they'll be able to open their mail file until their user.id expires.

So, one thought in this scenario - when creating user ID's, set them to expire in a short amount of time. It will cause you more work as an admin to update expiration dates much more frequently, but if you can expire a user's ID after say, 3 months, that will limit the time they can access it.

If there is a possibility that the user's PC will connect back to the server 'one last time', you can remove them from the ACL of their mail file, or better yet, set their ID to 'No Access'. But I think that will only work if you have 'Enforce a consistent Access Control List across all replicas'.

Keep in mind, once you've granted a workstation access to the data, it can be exported and downloaded or copied to another database. So there's no real security here. Once someone has a copy, they have a copy.

That said, there are a number of things you can do. It's possible to set up replicas so that you can replicate-out the lack of access to the documents in the DB. Then the replication event will remove all the documents from the DB.

But it is always a good idea to experiment on a copy before you set this up. Removals of this type are forever -- if you inadvertently turned this capability loose on the server replica -- they'll all go away.

It's also possible to set up selective replication on a database, and it'll serve the same purpose.

So just take some care when you're experimenting, and don't do it in production until you're familiar with the gotchas.