In addition to the tips provided, e.g.:
If the gateway is not managed by the same SMS as your 1400 (e.g. if the 1400 is locally managed):
a) You will need to create CSR on the 1400 and sign it from the ICA of the SMS. You will also need a static NAT on the SMS so that the 1400 can fetch cerificate revocation list from the SMS ICA, or disable CRL retreival on the 1400.
b) In SmartConsole define certificate matching criteria on the object representing the 1400 series gateway, so that the 1400 can be identified by it's certificate.
c) On the 1400 series gateway you must define the tunnel as a permanent tunnel so that it will always initiate the tunnel. otherwise you sometimes will be unable to bring up the tunnel from the central gateway (gateway will not know which IP to connect to).
If the 1400 series gateway is centrally managed, certificate will be used automatically, and you just need to define the VPN community for permanent tunnels, otherwise you sometimes will be unable to bring up the tunnel from the central gateway side (gateway will not know which IP to connect to).
And of course, VPN encyption domains need to be created for local/remote. The VPN encryption domain should be what networks exist behind the local gateway in question, which should be allowed to talk to the subnets configured on the remote side. You can easily base it on network topology if both peers are centrally managed and network topology is defined, otherwise you can use a network object or create group of networks.
Standard firewall rules to allow connections over the tunnel, on central side populating VPN community column of the rulebase is not necessary unless using traditional mode VPN (most likely you are not).