Your comments

We've never seen that appear typically because we add new employees to the organisation from the management side, rather than letting the new employee register themselves. (We know the email address will be one on our own domain name so we just make it.)

If we make the user but then don't assign any workspaces, would the user then get the prompt to join many workspaces at once on their first login? Or do they have to register themselves then be invited to the organisation?


Hi Ryan,

That's useful to know that a particular colour will be default rather than anything random within the rainbow.

Looks like someone else has already filed a request for organisation imposed workspace colours:

Hi Ryan,

Thanks for your feedback. We typically only colour workspaces that are purpose specific (typically green for internal and red for client visible). Other than that we have no purpose for colours.

Would it be within scope to choose a default colour instead? What we don't like is a new workspace being added to find that it's got some random colour we didn't opt for. (Particularly if it uses the same colour for internal or client visible workspaces as it may get missed by some of our colleagues.) -- Good to hear that we won't have to go through extra clicks to choose a colour, but with the absence of organization imposed  workspace colours, I wonder how this would work for everyone else in the organisation that didn't add the workspace.

This is important.

We have around 30 active workspaces at any given time, and probably around 60+ archived ones, as we make a new workspace for each client project.

When a new employee starts with us either me or our boss needs to spend the next 10-15 minutes tediously adding the new employee to all of our workspaces.

Yes, we would like this too. We primarily use workspace colours as follows:

Green: Internal only

Red: Project for a client, of which the client can see the workspace as an external user

No colour: Projects for clients

We'd like the option to enforce a workspace colour in the first two instances, so nobody forgets that a client can see what is being commented etc.

Hi Ryan,

Thank you for this update. The reddish first new colour is very suitable for us to mark workspaces that are client visible.

I noticed that the option for no colour is now missing though? That means as soon as a workspace gets a colour it can never be set to colourless again. (Most of my workspaces are colourless, with the exception of internal only ones as green, and client visible ones as red.)

I'd very much like this too.

My current workaround is to create 4 tasks (1/Jan, 1/Apr, 1/Jul, and 1/Oct) and have each of those repeat yearly. Not ideal though...

An option for biannually would be equally useful.

Is there any news on the bug I posted related to this?

Since this update the workspaces using now non-existent colours have turned white, however attempting to choose a new colour does not save properly. (Only until you refresh Redbooth, which needs to be quite frequent to keep up to date.)

The AJAX request looks like it does not include the project ID in the URL or POST data, so the Redbooth server may not know which project the colour should be persisted with.

Hi Claire,

It's not just you that were using this feature.

Our company used them to distinguish which workspaces were non-standard, typically because they were internal only (blue), or a workspace a client can also interact with (red).

I had filed support ticket with a question about this, and got the following response:

  • Yes, the change is intentional. Our Product team considers this change will bring a more consistent look across platforms. If you don't consider this change convenient, please submit your feedback in our forum so they can review it.

The option for an organisation do define their own custom colours would be the ideal option if the preset range is going to be this much narrower.