How would you track user access changes in Service Desk Plus for a pharma environment?

November 15, 2026 4 answers
Asked by Dovren.2k

We have an on-premises Service Desk Plus instance with Active Directory sync. We want to record access changes made in other systems, including the affected user and system, so we can report on them later.

Requests may come from a manager for several people. Would separate requests or tasks work best, and should the computerized systems be represented as assets?

Answers

d409~letterbox_7

Keep the requester and the person whose access is changing separate. A manager can submit the request, while an affected-user field identifies the person receiving the access. Use a lookup against the synced user list rather than asking someone to type a name.

I'd also capture the target system, the account changed, the approval, and the person who performed the work. That gives you a more useful record than a name buried in the description. Check which fields and lookup options are available in your on-premises version before settling on the template.

q.38+lanecheck_712:

The affected person and the account may not always be the same identifier, so it's worth recording both when needed.

Reply to this answer
g.84+turnip_16

For a request covering two people, I'd lean toward one access-change record per person, linked back to the original manager request if your setup supports it. That makes reporting and tracking each person's work more straightforward.

Tasks could be less cluttered, but first check whether your on-premises task fields support the user lookup and reporting you need. If they don't, separate requests may be the cleaner option.

Reply to this answer
c.26!pocket_804

You don't necessarily need to model every computerized system as an asset just to identify it on a request. A controlled system field could be enough for service desk reporting, while the fuller system inventory and qualification records stay in your existing change control system.

Whatever you choose, test that the system value can be selected consistently and included in the reports you need.

Reply to this answer
Tervel_9n

Be careful about treating the ticket alone as proof of what happened in the target system. It can document the request, approval, and reported execution, but you'll also want to consider what evidence the target system provides and how your organization's compliance process expects it to be retained.

Try a small workflow with a multi-user request and run the intended reports before building out the whole configuration.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions