docs: V2 alpha readme (#3669)

* docs: add actions dok from v1

* docs: change readme

* remove billing which will be redone

* fix search

* use readme branch to test index

* fix algolia

* fine tune

* tweak

* test

* Update netlify.toml

* Update netlify.toml

* Update docusaurus.config.js

* Update docusaurus.config.js

* Apply suggestions from code review

Co-authored-by: mffap <mpa@zitadel.com>

* tweak readme

* Apply suggestions from code review

Co-authored-by: Silvan <silvan.reusser@gmail.com>
Co-authored-by: Fabi <38692350+hifabienne@users.noreply.github.com>

* fix broken part of contrib guide

Co-authored-by: mffap <mpa@zitadel.com>
Co-authored-by: Silvan <silvan.reusser@gmail.com>
Co-authored-by: Fabi <38692350+hifabienne@users.noreply.github.com>
This commit is contained in:
Florian Forster
2022-05-20 16:20:31 +02:00
committed by GitHub
parent 40d7dba574
commit 220c8e4922
11 changed files with 416 additions and 107 deletions

View File

@@ -0,0 +1,38 @@
---
title: Actions
---
By using ZITADEL actions, you can manipulate ZITADELs behavior on specific Events.
This is useful when you have special business requirements that ZITADEL doesn't support out-of-the-box.
:::caution
ZITADEL actions is in an early development stage.
In the [roadmap](https://zitadel.ch/roadmap), you see how we are planning to expand and improve it.
Please tell us about your needs and help us prioritize further fixes and features.
:::
## Why actions?
ZITADEL can't anticipate and solve every possible business rule and integration requirements from all ZITADEL users. Here are some examples:
- A business requires domain specific data validation before a user can be created or authenticated.
- A business needs to automate tasks. Roles should be assigned to users based on their ADFS 2016+ groups.
- A business needs to store metadata on a user that is used for integrating applications.
- A business needs to restrict the users who are allowed to register to a certain organization by their email domains.
With actions, ZITADEL provides a way to solve such problems.
## How it works
Using the actions feature, *ORG_OWNERs* create a flow for each supported flow type.
Each flow type provides its own events.
You can hook into these events by assigning them an action.
An action is composed of
* a name,
* a custom JavaScript code snippet,
* an execution timeout in seconds,
* a switch that defines if its corresponding flow should fail if the action fails.
Within the JavaScript code, you can read and manipulate the state.
## Further reading
- [Assign users a role after they register using an external identity provider](../../guides/customization/behavior)
- [Actions reference](../../apis/actions)

View File

@@ -36,4 +36,7 @@ Please be reminded that ZITADEL is open source — and so is the documentation.
<ListWrapper title="Use Cases">
<ListElement link="./usecases/saas" type={ICONTYPE.START} title="SaaS" description="Product with Authentication and Authorization" />
</ListWrapper>
<ListWrapper title="Features">
<ListElement link="./features/actions" type={ICONTYPE.FILE} title="Actions" description="Customizing ZITADELs behavior using the actions feature" />
</ListWrapper>
</Column>