Raising a Reclamation record when a closed skip instance exists

[Michael Morgado]

I have a situation where a restricted reclamation record was set to closed skip as the users received a temporary exemption for the software.  The exemption expired and we want a new restricted reclamation record to be triggered.  We have noticed in the past this does not occur.  When i manually tried creating the record I receive an error that an existing RCC already exists and a new one cannot be created.  Is there a way around this issue?

I have included a screen shot of the error messages returned

[Vikram Reddy]

Hi @Michael Morgado 

This is a known rough edge in the OOTB reclamation flow, and I have run into it on a few implementations. The short version: the platform does not dedupe Reclamation Candidate (RCC) records by state, it dedupes by the software installation and user pairing itself. A Closed Skipped record still counts as "a reclamation candidate exists for this install," so when you try to insert a brand new one manually, the same validation that normally stops a duplicate open RCC from being created also stops you here, even though the existing one is closed.

What is actually going on architecturally: the Reclamation Candidate table (samp_sw_reclamation_candidate, extended from Task) is designed to carry one lineage per software installation, not one record per reclamation event. When conditions recur, for example the software gets reinstalled or, in your case, an exemption expires, the intended behavior is for that same record to be reopened and pushed back through the workflow, not for a second record to be created alongside it. For usage based candidates there is a dedicated scheduled job, SAM - Updating Existing Reclamation Candidates, that revalidates existing RCCs and can flip them back to active when the underlying condition reappears. Restricted software reclamation does not get that same automatic revalidation, so nothing reopens your record when the exemption window ends, and you are left with a Closed Skipped record that blocks a new insert but never reactivates itself.

So the fix is not to fight the duplicate check, it is to work with it:

1. Open the Reclamation Candidates list and remove the default active-only filter (most list views default to something like state != Closed), then filter on the specific software installation or CI and user to locate the existing Closed Skipped RCC.
2. Reopen that record instead of inserting a new one: reset State back to New or Open (whatever your workflow's pre-approval value is), and clear the closure notes, closed date, and skip justification fields, then save. Because you are updating the existing record rather than inserting a row, you will not trip the "an RCC already exists" validation.
3. Let it run back through your reclamation workflow, or manually progress it, so the restricted software approval and removal path fires again.

If you want this to stop being a manual chore every time an exemption lapses, build a small scheduled job or flow that queries samp_sw_reclamation_candidate for Closed Skipped records where the linked exemption or exception has an end date in the past, and have it reopen them the same way the "Updating Existing Reclamation Candidates" job does for usage based RCCs. There is an open, unanswered thread on the SAM forum asking this exact question about whether closed or skipped candidates get recreated automatically, Close Skipping a Reclamation Candidate, so I would not assume OOTB behavior handles it for restricted rules without confirming it on your version. There is also a good thread on the mechanics of RCC approvals and why reopening the existing record is the expected pattern rather than recreating it, Reclamation Candidate - What BR / Script Generates the User Approval, and the platform docs on reclamation rules for reference, Software reclamation rules.

Thank you,
Vikram Karety
Octigo Solutions INC