20
Is it possible to restrict a User to a specific Brand's Portal?
Idea shared by Michael - 9/17/2014 at 8:31 PM
Declined
Can it be done so that a certain user has access to the Portal (News, KB, Tickets, Community) for only 1 or select number of the Organization Brands?
 
On the surface it seems a User has access to the Portals of all Brands.
 
Perhaps it can be limited with User Roles?

59 Replies

Reply to Thread
0
Guess not?
5
Andrea Free Replied
Employee Post
Hi Michael,
 
It's not currently possible to limit the brands a user can see. However, when using host headers your portals will have separate URLs. You would want to give the URL to only the users who should have access to that portal. 
 
This has been requested in the past and I can see the benefit; I'll go ahead and change the status of this to an Idea so others can vote on it and give their input as well.
 
Thanks!
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
0
Imagine that you have one brand for external customers and one brand for corporate employees. Both the employees and the external customers would be considered users by Smarter Track. It would be important to make sure that the external customers can't get a hold of the community meant only for corporate employees. If the customer gets a hold of the other URL they'd have access to information they shouldn't have. Seems to me a sensible solution to make one installation more flexible.
0
Andrea Free Replied
Employee Post
I can see the need in your case. A work around you might implement is to create private Categories in your corporate brand's Community. Doing this would allow you to limit those threads to only the users with the specific role. You can read more about how to create a private Category here: Create a Private Community Category
 
I hope this helps!
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
0
Can the same be done for News and KB?
0
Andrea Free Replied
Employee Post
At this time, only the Community supports private categories. There wouldn't be a way to do this with the News and KB.
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
0
Do I understand correctly that this functionality to restrict a certain user to a certain brand is available in Smarter Track 11 BETA?
0
Does version 11 address this issue?
0
Andrea Free Replied
Employee Post
Michael, I don't believe there have been changes in 11.x that apply to this functionality.
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
0
I completely agree with Michael. We have the exact same problem, in fact we have departments such as HR that are using smarter track. There are so many reasons why this is limiting our ability to completely deploy smartertrack across our entire enterprise. Can you imagine if a customer had the URL for our HR department? It doesn't make sense that you cannot add some ID's to the database and completely separate users by allowing us to explicitly assign permissions to each brand. In other words we have to link a user to a brand, if that user did not have permissions to that brand they would be unable to view anything related to that brand. If the user is a valid user, maybe give them a link that says, request permission to this brand or something like that... But this is a serious problem and must be addressed. It is making us have to seriously consider other options.
4
I also want to add my voice into this idea. We just purchased SmarterTrack a few months ago and ran my first "training" class with the first department in our agency that will be using the system. We are planning on using the "branding" feature so that we can have multiple portals for all the different divisions in our agency.
 
We are finding that some divisions want to restrict the creation of user accounts, meaning that an administrator would be creating the account manually for our customers. However there are other divisions that want to allow users to create their own accounts.
 
The problem is that since user accounts are not "Brand" specific, if we have two Brands with competing account creation policies, they in essence step on each other. For example, Brand A has user creation locked down. Brand B has user creation open to the public. In many cases, our different divisions have the same customers (We looked into using departments but that wasn't viable, using brands worked better). So if a customer from Brand B creates an account, they have the ability to submit tickets and such to Brand A's portal. Even though Brand A never designated that user as being allowed to access support from them. Right now the only alternative would be to install them as separate instances completely, which then opens us the need for multiple license purchases and other logistics that are just too cumbersome.
 
Being able to designate on each user account which "Brand" they have access to would be a HUGE step in giving us flexibility on controlling user submitted help requests.
 
We would love to see a Brand auto assigned to a created user account should that Brand allow for public registration...but for those Brands that do not allow it, an admin can edit the User Account and "check" off the private brand so they can gain access. Or...an alternative idea is that any brand that is set to allow public registration will allow any registered user access to the Brand's portal, regardless of whether the Brand is authorized or not, since it is a shared system. However if the Brand is set to "private" account creation, then only those user accounts that have been given explicit rights would be allowed access to that Brand's Portal.
____________________________________ Ben Santiardo, Senior Programmer Analyst Eastern Suffolk BOCES
1
We're more than a year into this idea. Any chance it will catch on or be implemented?
4
Look forward to updates from Smarter Tools on this one.
0
Ditto, this is essential to making brands useful.
0
Is there a status on this? Certainly something that we desire.
1
I agree with this idea :)
If you work collaborate with your partners company, I think you will like my idea here:
portal.smartertools.com/community/a88643/restricted-privileges-agent-to-see-only-customer-client-with-same-brand-where-customer.aspx
0
Is there a status on this???? 
2
It would be great to know an update on this 3 year old request.
1
Starting to feel that Smarter Trak... as far as interaction and a road-map .. from SM.. is not too much of a priority...   Have been patiently waiting (now going on three years.. for some subjects) .. with a comment of post from SM.   This particular  post is near and dear to our needs.. but has not been updated since September 26, 2014.
 
 
0
Right there with you. The permission handling in SmarterTrack is way behind the times, and their responses to these posts have the "it's so messed up behind the scenes we just don't know how to fix it" vibe to it.

We have lost a lot of potential customers due to this. They want back-end access to view tickets and see the progress of them.

There are no reports that do this. None of the reports have any detail to them, can't see custom fields, can't see a list of tickets opened with their Ticket # and subjects, etc. There are only two Call Log reports, Overview and Trend. Can't even see the total amount of minutes on them, just averages.

Can't have them view it in the portal since that only works if the email address is the same as the registered user in ST.

Can't give them back-end access to allow their team members to work on tickets because then they'll see our other clients and there is no way to prevent that.

It's become quite obvious that SmarterTrack is not the proper tool for a MSP provider, and when I see that the next new version highlights is improvements to the chat system (seriously? who uses the ST interface for intercompany chat??), I can see it will never be.

Which is why I just had a meeting with a competing ticket system vendor, which seems to do everything ST does, but better. As they actually understand how permissions are supposed to work in this day and age with proper reporting. We refuse to lose anymore money because of this product and by the end of November will be moving to something else.
0
Right now, we just need it for the documentation and knowledge base side...... we have decided to code part of it, if necessary... but that really isn't our desire.

Its the lack of response that I am becoming flustered with.
0
Goes hand in hand though with basic permissions. If a user has access to Brand A. These permissions should be throughout the entire system. KB, Call Logs, Tickets, Reports, etc. But, that's not the way SmarterTrack was designed to work.

Most programs out there work with permission hierarchies. You are assigned to Brand A, that's all you get to see. After that the permissions break down to what the user is allowed to see on a Brand/Account basis. This is basic stuff. ST is one of the few expensive programs out there that doesn't do this.

And their lack of communication on this multi-year issue, request has pushed our patience much further than it's needed to go. Their old forums had several threads on this, this forum if you search has a few requests on this, but nothing. My personal opinion, ST would need a complete code do-over to implement something that should have been in place since the start.

Since they have no interest in pursuing this, and I'm not going to spend time fixing their code, just to have it overwritten every upgrade, we must go elsewhere. I've waited several upgrade cycles now and spent the past couple years waiting. No longer.
0
It'd be great if this feature could be implemented.
0
Smarter Tools, this is from 2014. Any update for us?
0
Will this be considered for Smarter Track 13.x?
0
Andrea Rogers... we're on v13 now. Any hope of seeing this feature?
0
Can we do this now in Smarter Track 13.x?
0
I am guessing that due to the lack of response from ST, this is not implemented. This should have been done with a simple join table in the database. User A can have certain permissions within each individual brand... Or simply denied access in another brand. That would have worked for us. We still own the product, but cannot use it as we intended to. ST has a lot of potential and may serve many well. But when people, and seemingly many people need and request a feature that should be relatively easy to implement it gets frustrating. I keep paying for my maintenance hoping they add this, but we are soon to stop paying as we have found an alternative that seems to have everything we need.
1
As we are now planning to implement separate brands per customer, we also wish to see this feature implemented ... and therefore have added our vote.
Since our customers now have our default brand, we want to make sure we send them to their custom branded site.  If they still have access to the default brand, it will create some needless confusion and just will not be an easy transition.
0
May I inquire about your alternative?
____________________________________ Ben Santiardo, Senior Programmer Analyst Eastern Suffolk BOCES
0
This appears to be the 2nd highest request by Smarter Track votes. So I hope some point soon we can see it. It would make our implementation of Smarter Track much more useful.
0
At this point, Michael, not sure if anything will prompt ST to incorporate such a basic feature. Maybe if/when they start losing customers and get feedback that it's because they are not implementing basic features? Who knows...
____________________________________ Ben Santiardo, Senior Programmer Analyst Eastern Suffolk BOCES
0
In 2014 Andrea Rogers opened it for a vote and it seems clear this is wanted. So Maybe this can be our 2017 Christmas gift from Smarter Tools? I know that Smarter Track is primarily used for Smarter Tools to communicate with Smarter Tools customers (re- Smarter Mail support issues, etc) and perhaps since Smarter Tools doesn't have multiple brands in-house they don't see the value, but I'm keeping positive that this will get implemented. It seems the community has spoken on it.
0
I agree that the community has spoken on it.  The issue seems to be how to get this in front of the developers so that they prioritize it.  Continuing to bring up the features that we really need, often, will at least give the ST team something to say NO or YES to.
 
Personally I am now waking up to the power of Brands (sorry, a bit late to the party) -- but there are some missing pieces related to branding that we need.
 
If the developers have a feature "under consideration" AND has a high number of votes, as does this request, then it's perfectly fair for paying customers to ask the question:
  • When (a date please) will we see this feature?
1
Wouldn't hold my breath. I understand some of you are "new to the party", but here is some perspective.
 
On their old forums about 5 years ago, this was a wildly requested feature. There were several different posts about it. A handful of them got responded to by the SmarterTools team that they understood that the feature made sense and would put it under consideration (sound familiar?).
 
Then they switched to the new forums we use now, and there are several threads if you care to search for them regarding this feature request. All have been buried and little have been responded to. This particular thread is over 3 years old with lots of votes (as was the others) a response from the community team and more responses from customers years later.
 
It is now going on 6+ years of asking for it, about to be 2018 and the best we got with the new version of SmarterTrack was "new chat, and changed up interface".
 
What I'm getting at here, don't hold your breath for it. There is more than just restricting people to brands. There is the chats, tickets, call logs, knowledgebase, portal, canned replies, management interface, etc etc. I believe it would require a complete rework of many things and that is why it hasn't happened yet.
 
Apologies if I come across a bit salty, I'm just frustrated my company has lost business because of the lack of this basic feature almost every other ticket system that does multi-brand/company does. And switching systems is not a overnight thing when you're doing several thousand tickets a month.
2
I'm going to stay positive and hope that Smarter Tools will respond to us on this very popular thread vs. remain quiet and just let us go back and forth among ourselves.
0
Lets all sing together now.. . "All I want for Christmas from ST, is brand/user interaction"
...... Or at least some sort of acknowledgement of this request... Its been more than 3 years...
1
Ok, Christmas 2017 has come and gone.... what about a reply before the year is up??
Pls... I don't understand, why this thread doesn't receive a response from ST staff :(
 
1
Agree with Merle. 
 
Would someone from the SmarterTools staff kindly let us know the status of this request, which is over 3 YEARS old?
0
Just FYI.... Michael.. et al....

We have given up on this....... and have moved on.
We coded our own front end that uses STrak KB files... but the login and control for the users looking at knowledge base is now under our own code. We couldn't wait any longer.. and there was (is) no response from SmarterTools.. for whatever reason.
True our "support" portal may look a little disjointed.. but we had to move forward and code around.
If they ever change their mind, we'll take another look at it, but for now... that is the route that we are going.
0
AGREED!
0
Eric McCarthy Replied
Employee Post
This is still under consideration and an ongoing discussion point. Introducing this capability would require significant changes to how many of the features in SmarterTrack currently work. The changes required to make this work would be system wide, and would effect every part of the software. Since these changes are so significantly different to how it functions now, the discussion is a long, detailed and cautious one. 
Eric McCarthy Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
Eric, Had SmarterTools listened to their customers 3 years an 50 features ago, this would not have been so difficult to implement. It's getting harder and harder to do business with ST. My email still isn't what we need in V16, so I am still running without many of the new features in 15. SmarterTrack is feature limited at this point. I guess it's simply up to people like me to stop the bleeding and move on, but quite frankly I had a lot of good experiences in the past. However, the good is not outweighing the bad at this point. It seems you guys are very disjointed and lack direction at this point. But that is my opinion which I have formed from watching this unfold for many years.
0
Well.. for whats its worth...
I would be happy to provide the code and the table that I used to implement this on my own. As after thinking about it, it required:
Added a two new tables, added a new query....
One table relates to the kbarticle, one table matches to the users

New process handles the branding for us, pretty easy..  
(again, for whats it worth)   Would be happy to share if you desire.
'================

Merle
0
Any chance we'd see this in version 14? We're coming up on the 4 year anniversary of this post.
0
Eric McCarthy Replied
Employee Post
This feature did not make the cut for inclusion in version 14.
Eric McCarthy Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
Eric should we give up or hold out hope for version 15? Maybe after 5 years it will get sorted out? Or should we move on?
0
Andrea Free Replied
Employee Post
Hello everyone,
 
We met this morning to discuss the requested features list for future versions of SmarterTrack and had a long discussion about this request. In an effort to be transparent, we'd like to discuss some of our concern and hesitation about implementing this change. 
 
As Eric mentioned above, introducing this capability would require significant changes to the way many of SmarterTrack's features currently work. There are many overlapping pieces to be considered. For example, if multiple brands accept user registration at the portal, how do we handle a user who's registered with Brand A attempting to register with Brand B? Do we reject their registration since they're already a user of Brand A? Do we allow them to register to Brand B and duplicate their user account within the database? Duplicating user accounts could pose its own issues, with organizations and reporting that look for specific user accounts. It seems this implementation would only be possible if there aren't any users that are shared between the brands and the brands do not allow user registration at the Portal.  
 
That said, each brand utilizes its own host header to achieve separate Portals with separate URLs. As long as the brand's URLs are not being advertised to users from both brands, the users from Brand A should not have any knowledge of the Portal for Brand B, and vice versa. Have you found this to be an issue with users from Brand A accessing the portal for Brand B? Are both brands advertised to both sets of users? Please help us to understand your specific use case and what type of logistics you would like to see with this implementation. Please understand we aren't hesitant to put in the hard work for a feature to be implemented, especially one that's as heavily requested as this. We just need to ensure everything is considered carefully. 
 
Thank you, 
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
0
If we are using Smarter Track hosted we can only have one HTTPS host header. If hosted will allow multiple SSL host headers maybe this can be accomplished, but currently you're only allowing one host header to be SSL. And, as you know Chrome and others want all sites HTTPS.
0
Andrea Free Replied
Employee Post
Michael,

Do you have an idea of a workaround that would restrict a user's Brand access if SSL could be accomplished on all host headers?
Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com
0
Andrea, if you guys could find a way for HOSTED Smarter Track customers to enable SSL on host headers... then I think you're asking if this can work for us?

I think the remaining issue is that if you end up at Brand B and search KB articles, won't you be able to see articles from Brand A?
0
Andrew Barker Replied
Employee Post
Michael,

KB articles are filtered on the portal so that they are only visible to the brands they have been associated with. In the scenario you presented, as long as the KB articles are linked only to Brand A, then they will not be visible to users searching for KB articles on the Brand B portal.
Andrew Barker Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
@andrew the question is not about agents. It's about customers. We don't want customers who know us as Brand A to be able to search for article from Brand B.
0
Andrew Barker Replied
Employee Post
Sorry, I meant to say "users" since, in this respect, we don't differentiate between customers and agents on the portal. I have edited my previous post to correct this.
Andrew Barker Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
@andrew so it is possible to password restrict a brand and then associate KB articles/news only to that brand? Thus users of Brand B can only see content for Brand B if they are granted access by the admin vs. sign up on a public page they may find in a google search.
0
Andrew Barker Replied
Employee Post
Brands are not password restricted. The current configuration uses the host headers to determine which brand the user is viewing. For example, if I have Brand A and Brand B, with Brand A as the default brand and Brand B with a host header of b.example.com, all requests to b.example.com will be treated as belonging to Brand B, and requests coming to any other host will be treated as belonging to Brand A.

Visibility of KB articles is dependent on brand permissions, role permissions, and KB article settings. Using the Brand > Permissions > View KB Articles Requires setting, any brand can be configured to restrict the permissions necessary to see KB articles. Any value for this setting, other than All Users and Nobody, will require users to be logged into the portal in order to see KB articles. If you need to restrict the visibility of certain folders of KB articles, this can be done by creating roles with customized KB Article permissions. Finally, when editing a KB article, it can be assigned to one or more brands by adjusting the settings on the Brands tab. Using my previous example, a KB Article associated with only Brand B will only be available when accessing the portal through b.example.com. Aside from the ability to restrict folder visibility using role permissions, all of this can be done with news items as well.

This means that what you are describing can be accomplished for KB articles. If you have Brand A and Brand B, and want Brand B KB articles to be restricted to users with a specific role, do the following:

  1. Use separate KB folders for each brand.
  2. On existing KB Articles, edit them to ensure they are assigned to the appropriate brand.
  3. For the existing user roles, customize the KB Article settings so that they only have permission to see the KB folders associated with Brand A.
  4. Create a new user role that grants permissions to see the KB folders for Brand B. Assign this role to any users you wish to be able to see Brand B's articles.
  5. To completely hide the KB Article section on Brand B's portal from users who are not logged in, got to Brands > Permissions and change the View KB Articles Requires setting to "Registered Users", or something more restrictive.
Using these settings, a user visiting Brand A's portal will only be able to see KB articles associated with Brand A. For those users visiting Brand B's portal their experience will depend on whether they are logged in and the roles that have been assigned to their account. On Brand B's portal, an unauthenticated user would not even see that there was a KB section, while an authenticated user would see that the KB section is there, but they would only see the articles if they had the appropriate role. Note that any user with an account would still be able to log into either brand's portal. Those without the custom role would simply see Brand B's KB section as empty.
Andrew Barker Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
Andrew Barker Replied
Employee Post
Based on recent conversation, it appears that the use case for this request is already handled by other settings within SmarterTrack.
Andrew Barker Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
1
Andrew,

Just wanted to chime in on this. You said that based on the recent conversations that the use case is already handled by other settings? I beg to differ. There is nothing to prevent a "user" from accessing any of the portals available. "Users" are not given permissions to specific portals, which is the whole entire premise of this thread. We ourselves need the ability to restrict users to access the portals they are meant to access. This lack of feature is preventing us from expanding our use of your software, because the ONLY way of being able to do this currently is to have completely different installations, which means different usernames/passwords, etc.

Just because we don't "advertise" the domain of a portal, doesn't mean that customers can't talk with one another and somehow find out about them.

Is SmarterTools wants to deny this feature request from their customers because it's too much effort (which I don't feel it is as I am a web developer myself and deal with these types of issues of security access all the time), then just say that ST is refusing to implement this request. But to say that the system has existing features to address this issue is a gross overstatement. Just my $0.02 ...
____________________________________ Ben Santiardo, Senior Programmer Analyst Eastern Suffolk BOCES
0
We are company a software development company; this how we got around SM issue:

In a "brief" summary, we added 1 table, added one webform, adjusted one query.
a.) added one more table to match with ST.. with USERID  and BrandID and Yes/No Flag.
     (so this is where you set what USERID is authorized with what brand)
     +--> we had to build our own webform outside of ST to do this .. but still, one web-form.
b.) added query to join tables on knowledge bases that USERID is authorized with.
     so userid can only see what brands they are authorized for.
'===================================
In full disclosure, we now use our own "front-end" for the knowledge base for clients to use.. because we were also dealing with the single-sign-on(SSO) issue .. traversing back-n-forth between SmarterMail and SmarterTrack.   One might think that SmarterMail would talk to SmarterTrak - but not that we can tell (using signon credentials from SmarterMail to get to SmarterTrak
'===================================
Only reason I even write this at this point.. is to note that we had quit replying or asking for updates on this feature////because we "had to have it" .. and couldn't wait on SmarterTools. So we coded it ourselves.
We had to have this feature.. because when you offer more than one service.. linking back-n-forth AND trying to "stay" in the same address brand header did not work for us.  


Reply to Thread