ContributionsMost RecentMost LikesSolutionsRe: Great SEO Builds Community, and Great Community Improves SEO Subscribing to get any updates on progress with structured data issues. Re: SSO Map "Department" to User In our SSO implementation, we map departments to roles. This is already in the SSO integration and shouldn't require any intervention by Khoros support. This then gives us options for limiting permissions based on department/role, so we can have forums that are restricted to members of a department. Keep in mind that these will only 'sync' when the user logs in via SSO - so if an employee changes departments in your company, that change isn't reflected until the next SSO login to Khoros. Also, the SSO integration has two arrays - a "grant" and "remove". A user will continue to have a role via SSO until that role is passed in the "remove" array. In our implementation, we pass both on every SSO login just to make sure the roles in Khoros are up to date with our internal systems. The "grant" will have all the roles they should have, the "remove" all the roles they should not have. Re: OneTrust Cookies Consent OneTrust has test & production environments and uses different scripts for each. Any guidance on how that can be implemented in Khoros - i.e. using one script on Khoros staging and a different one in Production? We are planning on injecting the script objects into the HTML <head> using the "wrapper" of the skin we are using on our site. Re: OneTrust Cookies Consent Looking for feedback on this as well, as it's on the roadmap for one of my communities. Is it as simple as adding the OneTrust scripts to the head object on the site?