Help: How do I merge two duplicate issues? The function seems to be hidden.

You're definitely not missing something obvious - the merge function is a bit buried, and permissions do play a role. You need to be in the specific "Issue Management" module, not just any list view.

Here's the process I use: First, navigate to **Risk > Issue Management** in the main menu. From the list there, check the boxes next to the two duplicate issues you want to merge. The "Merge" button should appear in a toolbar above the list. If it doesn't, it's likely a permissions issue; you might need your system administrator to verify your role has the "Merge Issues" right enabled in the security settings.

A quick tip: the issue you select *first* becomes the "primary" issue that retains its ID and history. All details from the second issue get rolled into it. Always double-check which one you pick first, as you can't undo the merge.

That's a classic gotcha, and the other reply is spot on about it being tied to the Issue Management module. The bulk edit view or the issue's detail page won't have it.

One extra nuance: even inside **Risk > Issue Management**, the list view might have different "modes". Make sure you're on the main 'All Issues' tab or a standard list view, not a pre-filtered dashboard widget. The toolbar with the Merge button can fail to load in some of those embedded views.

If you have the permissions and are in the right spot but the button's still missing, a hard refresh (Ctrl+F5) sometimes does the trick - the UI can be a bit sticky. And you're right to be careful about which issue you pick first; the primary issue's ID is what everything consolidates under, so choose the one with the most complete history or the correct original due dates.

That point about the primary issue's ID is critical for audit trails. If you merge into the wrong one, you lose the original reference numbers people might have in emails or reports.

Also, the secondary issue's attachments and comments get moved over, but check the activity log afterward. Sometimes custom fields don't merge cleanly.

You're right, the merge option isn't in any of the obvious menus. I was stuck on this last week. The key for me was that I needed to select the issues first, then the button showed up.

Are you clicking on the actual issue rows to open them, or just viewing the list? You have to check the boxes on the left side of the list in the Issue Management module. Only then does the top toolbar appear with the Merge option. If you're clicking into each issue's own page, you won't see it.

Since you're on a SOX setup, does your role have "Editor" permissions on the issue module? That tripped me up at first.

The merge function is genuinely obscure, and you've correctly identified the main pain points. Beyond the module and permissions, there's another layer: the interface is context-sensitive to the specific grid configuration. If your administrator has customized the Issue Management view by removing the default checkbox column, the option to select issues (and thus the merge button) won't render at all.

You mentioned a standard SOX setup, which typically uses the "Audit Issues" list. That's a different object and view from the core "Issue Management" module under Risk. They often have separate permission sets. Your SOX role likely grants you full access to "Audit Issues," but merging usually requires the broader "Issue Management" permission. This disconnect between compliance-focused and operational risk modules is a common architectural oversight in the platform.

A step-by-step isn't much help if the underlying security model is blocking you. The actionable step is to ask your admin to verify two things in the Security settings: that your role has the "Merge Issues" functional right enabled, and that you have "Edit" access to the "Issue" object type within the Risk category. Without both, you'll just be staring at the correct list with no toolbar.

That's a really sharp observation about the grid configuration. I've seen a few teams hide the checkbox column to 'clean up' the interface, not realizing it breaks core functions like merging. It creates such a frustrating support loop where the user thinks it's permissions and the admin thinks it's user error.

You've hit the nail on the head about the architectural disconnect being a common oversight. It often takes a specific request to an admin to bridge that gap between compliance and risk objects. I'd add that even after the permissions and view are corrected, the merge button itself can be finicky - it sometimes only appears after you've selected exactly two issues, not just one or three.

That's a great point about the hard refresh. The UI framework they use can definitely cache toolbar states incorrectly. I've had to clear my browser cache entirely before to get action buttons to appear after a permission change.

Your warning about pre-filtered views is crucial, too. I once spent twenty minutes looking for the merge option on a manager's dashboard because they'd pinned a filtered "My Open Issues" list there. It looked identical to the main module but was just a read-only snapshot.

Oh, the cached toolbar state problem is so real. I once watched a colleague toggle a permission on and off three times, convinced it was broken, before I suggested a cache clear. The merge button popped right up. It's one of those little things that makes you feel crazy until you figure it out.

And your dashboard story hits home. That separation between a functional module and a read-only dashboard widget is a massive UX pitfall. I've seen teams create entire "action" dashboards with those snapshots, only to generate a flood of "why can't I edit?" tickets. It looks identical, so who can blame them?

Exactly, it's those identical-looking widgets that cause so much confusion. The number of times I've heard "but it's right there on my dashboard!" is crazy.

That cache issue you mentioned is another silent killer. It's not just a refresh sometimes, either. On our SOX platform, I've had to log completely out and back in after a permission update for the toolbar to finally respond. The system seems to hold onto your old role's UI state way too aggressively.

Makes you wonder if the dashboard builders even know those views are read-only.

The cache issue is a persistent architectural flaw, not just a UI quirk. In our GRC platform, the frontend aggressively caches permission sets per session key, and a logout/login is often the only reliable purge. I've measured it, and stale toolbar states can persist through a dozen page navigations.

Regarding dashboard builders, they're often compliance analysts working from templates, not developers. They select a list view from a dropdown labeled "Issues," with no indicator it's a static snapshot. The platform vendor shares blame for making these read-only widgets visually identical to functional modules, down to the same CSS classes. It creates a perfect storm of user confusion and admin frustration.

I ran into this exact same problem last month. Everyone's right about needing to select the issues first, but there's one more step that got me.

After you check the boxes in the list view, look for a tiny downward arrow on the right side of the top toolbar. That's where the Merge option hides for me. It never shows in the main button bar, only in that dropdown overflow menu. I think it's because our admin added too many custom actions.

Could you try that and let us know if it works on your SOX setup? I'm curious if that's a universal quirk.

Ah, the overflow menu trap. That's a good catch. It's not just from too many custom actions, though. On some of our inherited views, the merge button was hidden there by default because the 'Standard Actions' group was set to overflow. The admin who built it might not have realized that choice would hide critical functions.

Your tip about the tiny arrow is spot on, and it highlights a bigger UI pattern issue. When you customize a toolbar, the system often pushes lesser-used items to overflow automatically. The problem is, "merge" gets lumped in with truly minor actions, making it invisible until you know where to look.

Yep, that automatic grouping logic is the real culprit. It's not just about what's considered 'lesser-used,' it's that the algorithm doesn't know the functional weight of an action. For a power user, merging is a primary function, but the system often sees its low click-rate and shoves it into overflow alongside 'Export to PDF.' I've seen admins fix this by creating a separate, permanent 'Issue Actions' group in the toolbar config, just to give merge a guaranteed home.

Ah, the "obvious" process. Except the merge button doesn't just appear, even with the right permissions, if you're in a custom grid view. You can be in the correct module and still not see it because some admin decided to hide the selection column for a cleaner look. So you're following the official steps to the letter and hitting a dead end. A classic case of the documented procedure ignoring the actual, messy configuration it lives in.