Access For Clients/Non-Developers in Fogbugz


Sometimes, you might want to set up “non-developer” users that can interact with Manuscript, but don’t need the full functionality of the application. Here are some different options, as well as ways to do this without using up licenses, or creating extra Manuscript users.

You’ve got a few different directions you can try to take, but at the end of the day, if you want someone to be a full user of Manuscript (i.e. be able to log in and edit cases, manage projects, etc.), that user will need to be a “normal user” in Manuscript with a purchased seat.

Full User (Administrator or Normal)

Manuscript is great for managing a body of work related to a project. While this of course makes sense for software development, people use it for all kinds of situations that may be only tangentially or not-at-all related to software development. If you want people to be able to work within Manuscript as a first-class user, managing and editing cases, that would require a full user license. Even if that person is not a developer, they are still fully utilizing Manuscript. With Manuscript On Demand, you can change your user tier plan, so you can ratchet up the number of users as you need them and remove them as needed. See also: User Types in FogBugz, Project Permissions.

Community Users

A free and limited functionality user, but he or she can logon to Manuscript. Read more here.


You can set up separate Mailboxes for individual projects. This allows people to create and reply to cases via e-mail. The ideal workflow for this would be a team of people who need to correspond to users on a case-by-case basis. It’s not intended as an overall project collaboration mechanism, but the process could be hacked to work that way. See also: Handling Incoming Customer Email, Using Manuscript to check POP3 and IMAP mailboxes, and Public Access to Email Cases

Custom Development

You have the ability to customize Manuscript via the XML API. The XML API requires a user, so we recommend purchasing at least one seat for your automated “user” that accesses the XML API. If you wanted to, you could expose information related to cases via the API. This allows you to create an interface that’s as complex or simple as you feel you need.