Merge pull request #225 from permitio/filip/per-8644-update-docs-for-…

…the-new-login

Quickstart now reflects new onboarding flow

docs/getting-started/quickstart.mdx

@@ -23,68 +23,26 @@ To get a custom quote on SSO, reach out to us via our **[Slack Community](https:
 
 :::
 
-## 2. Creating a workspace
+## 2. Creating a workspace & naming your organization
 
 First, you will need to create your workspace (Or, organizational account), under which all of your configurations,
 projects, and environments reside. This will often correspond with your company’s name.
 
 :::tip Example:
-We have a pizzeria called "Johns Pizza" - this is our business, so that's what we will call our organization
+We have a company called "Company A" - this is our business, so that's what we will call our organization
 :::
 
-![Workspace](/ui-videos/getting-started/quickstart/1.png)
+![Workspace](/ui-videos/getting-started/quickstart/onboarding.png)
 
 :::note
 You can have multiple workspaces and switch between them - although usually, you'd only need one. Workspaces are completely
 siloed from one another.
 :::
 
-## 3. Define your first policy
+That’s it! You can now launch your account! 🥳 Now that you have all the basics set up, you can connect Permit to a demo application and see your
+defined policy come to life.
 
-A basic [authorization policy](/overview/glossary#policy) consists of three elements: a **Resource**, an **Action**, and a **Role**.
-
-- Start by defining a **resource** - this is going to be the entity which you want to manage access for.
-
-:::tip Example:
-John's Pizza has a **Kitchen**, that only certain individuals have access to, and can only perform restricted actions in.
-Our resource is the Kitchen
-:::
-
-![Resource](/ui-videos/getting-started/quickstart/2.png)
-
-- Then, define the possible actions in regard to the defined resource.
-
-:::tip Example:
-The Kitchen will have three actions applied - **Enter**, **Cook**, and **Manage**
-:::
-
-![Actions](/ui-videos/getting-started/quickstart/3.png)
-
-- Now that we have a resource and actions defined, let’s add roles into the mix.
-
-:::tip Example:
-A **Chef** - Can **Enter**, **Cook**, and **Manage** the Kitchen.
-A Manager - Can **Enter** and **Manage** the kitchen, but not **Cook**.
-A Waiter - Can only **Enter** the Kitchen.
-:::
-
-- Using the UI, assign the relevant policies accordingly. Note that policy assignment can also be done via our API.
-
-![Assingment](/ui-videos/getting-started/quickstart/0.png)
-
-- With our new policy defined, we can assign the roles we created to actual users. Under “Email”,
-  fill in the actual users to which you want to assign these roles.
-
-![Users](/ui-videos/getting-started/quickstart/4.png)
-
-:::note
-Filling the emails of your actual users in this section is optional - in an actual application,
-users will usually be identified by GUIDs and not their actual data.
-:::
-
-That’s it! 🥳 Now that you have all the basics set up, you can connect Permit to a demo application and see your defined policy come to life.
-
-## 4. What's Next?
+## 3. What's Next?
 
 Now that you've seen the basics, you can dive deeper into utilizing Permit for your authorization needs.
 Here are some guides to get you started: