Global Knowledge base

aftechro

yep, most of us doing the same

johnny

@hugo is this a feasible solution?

hugo

For now yes, I also use like this.

litechforce

Hello,

I have a question about the Documents feature for companies. It is my understanding that this is used as a knowledge base of sorts. I am wondering if it might be better to have a central knowledge base built in. I say this because if a tech references a kb article/document that is not listed in the client's documents, it has to be copied/duplicated there so the client can see it. This creates duplicate articles, and then can become a maintenance nightmare (both system and knowledge).

Is this something on the road map? I apologize if this has already been answered.

wrongecho

litechforce

Merged into existing thread. It would definitely be a nice feature. The best closest thing we have now is document templates.

Alan

@litechforce we have two clients as such. One for ourselves (as if we were our own client, has our own assets) and a "! Knowledge Base" client (! makes it easier to search if needed). We then have a shortcut top right next to notifications that links directly to it's documents.

Documents that are specific to the client go into the client documents, everything else goes in KB. KB also holds temporary assets, eg, we have more firewalls than clients need, and they're kept there for issuing when needed. Keeps them away from our own client instance and assets related directly to us.

Absolutely agree re a global one (vendors is another where the same ones are duplicated through every client), but that's the workaround we've used.

litechforce

Alan

I can understand that. But what if multiple clients need access to the same documentation? You'd have to duplicate the articles/documents. That creates more problems because if you update one, you'll need to update all the copies as well. It would just be a nightmare. It would be better to have a central kb system with the option to mark the article as public or internal.

Also, having a way to allow a tech write an article, but have someone else proof read it and approve it for use would be nice.

Alan

Yep, agreed re multiple clients needing it. Having a centralised KB with documents that clients can access would probably be an interesting one to try and permission…

hugo

What I do today is a fake client named Knowledge Base, with documents in there.
Also I use the custom link to show it on main side nav.

so it opens directly on Documents section of that fake client.

Bigbug

hugo I also do this but i put it on top for easier accessibility

it serves its purpose but is not the best

focusflarenetwork

Bigbug damn that is cool I didnt know you can make folders in the uploads folder? I think that is what that is. My approach was going to host an internal wiki for myself and then just link it in the links section like someone else mentioned but I do like what you have too

uhdamm

Bigbug excellent idea - which I went on to test of course - but what do I put in "Icon" to make it visible?

For now it's blue on blue but it's there as the "hand" tells me there's something clickable, and the page loads okay.

wrongecho

uhdamm https://fontawesome.com/v5/search?o=r&m=free

uhdamm

wrongecho thanks, I'll give that a go.

Perhaps a subject for another thread or even outside the ITFlow scope but:

Where exactly do you put the fontawesome embedded header code (hosted), and will it be overwritten in future updates?

Thx 😊

JosephWithCOR

While it goes along with a central knowledge base, this suggestion might belong in it's own thread.

I would like the ability to share documents from my "company / document" or a central knowledge base repository with a client through their portal, not just as an emailed link. This way, I update my "master document" and it is reflected across all companies it is shared with.

Bonus points to include on the fly variables like company name. Example:

Document prepared for %CompanyName%

Would expands to when viewed:

Document prepared for @johnny

wrongecho

JosephWithCOR Yeah this is the debate between allowing something like sharing a document to all clients or just adding an actual KB module. The issue is that a KB module would essentially be a duplication of the documents module, except maybe with some more fields/visible to all client contacts by default.

JosephWithCOR

Not every document would need to be shared with every client. I have a document on "How to change your Windows password".

As the technician I will go to my company / documents because I have access to the system.

I am the MSP for @Bigbug. I share this document to his client portal because his computers runs windows.

I am the MSP for @hugo. I don't need to share this with him because his computers runs Linux.

However, I am co-managing as the backup MSP with @johnny. Because he didn't have anything prior, he is using our AWESOME system to track his stuff. I have a technician login restricted to his client and I have that same document shared with his client. Because it is a read-only share he wouldn't be able to edit, BUT, because he is a technician he would be able to author documents in his client. And, any document I share with him, he shouldn't be editing anyway.

How about share with a client (would cover Johnny's technician restricted login) and a checkbox for visible in client portal (would cover Bigbug and Hugo)? Edit - A visibility checkbox might not be needed because if a document is shared, it should be visible. Otherwise you are down the rabbit hole of who needs to see it, and I don't want to get into that. If I need to share a document that only @Alan needs access to, that would be the emailed link.

Now, your MSP Client / Documents folder becomes your knowledge base and all shared documents are a read-only symlink back to it. Edit one, all are instantly updated so you don't have to worry. This is why I suggested the %CompanyName% variable to make them feel special. I prepared this (shared) document specifically for them.

No longer need access? Remove the share with client, or uncheck the visible in portal.

Thoughts?

wrongecho

JosephWithCOR

I like the whole idea of having a single document that you "share" / symlink out to appear in different clients. I think it makes sense for this to be read only within each client and centrally managed. A single document on how to do X task with Y bit of software in the stack, updated in one place and visible to all that need it.

The visibility bit gets more complex.. Currently, making a document visible in the portal only allows users with the technical contact role to see it. We kinda made this up as we went along… initially technical contacts could see all documents, and then we added the visibility option, but kept it only to technical contacts.

Do you think it's worthwhile changing this visibility option into being visible for any contact user, or instead allowing both visibility options per document - making it visible to technical contacts OR all contacts? I don't want too much complexity, but still want to allow for the co-management stuff whilst understanding some documents are for internal use only.

JosephWithCOR

I did not realize that technical contacts could see documents in the client portal. In my instance, all but maybe three of my contacts have no checks. They are not important, in billing, or very technical.

For shared documents maybe default share to technical with a checkbox to make visible to everyone? This way you could share a more "internal" document with the technical folks vs everyone. And if it is an "internal" document, the tech folks would see it first without the risk of much leakage meaning someone in the portal at the exact right time.

I will grant extra access on a couple of clients in my instance to see what the client portal opens up.

Thank you.